Toward better service isolation
Services in EnOSlib is away to encapsulate common behavior and practice when experimenting. For instance the monitoring service deploys a monitoring stack for your experiment, the skydive service deploys a network analyser ... This is supposed to give ready to use tools to help the experimenter.
A service often requires software to be installed on the remote nodes and runtime to be launched. These are orthogonal with the experimentation requirements (software under study) and has currently some caveats (if not today, probably in the future).
First:
- any software change required by the service is global to the remote hosts (e.g some service requires python3 and make it the default)
- the runtime isn't isolated (I deem this to be less important right now).
When calling a service user can choose whether to install the requirements.
- if yes, a debian10 base system is also assumed.
- if no, the user is responsible for installing the requirements prior to the service invocation.
As an illustration, here what is enforced by the services:
-
monitoring
:-
python3
is installed if not present -
python3
is made the default python interpreter -
docker
is installed if not present (the runtime is containerised)
-
-
skydive
:-
python3
is installed if not present -
python3
is made the default python interpreter -
docker
is installed if not present (the runtime is containerised) -
pyyaml
is installed
-
-
locust
:-
python3
is installed if not present -
python3
is made the default python interpreter - At runtime any dependency required by the benchmark will be installed
-
The requirement of a service is captured by the notion of prior
, see e.g https://gitlab.inria.fr/discovery/enoslib/blob/232ef36e412873fb3d4a400e2882e3d2e5550c82/enoslib/service/monitoring/monitoring.py#L36
I am not very satisfied with the current state. Especially by the global changes (default python3) this might enforce silently to the experimenter.
I'd like to think to a better way to contain the effect of the service. Some solutions like on demand isolation (linux namespaces, chroot), lxc, or Nix pkgs might help. But ofc nothing is clear enough today.