In this notebook we won't execute anything remotely, instead we'll just cover some basic abstractions provided by the library.
In this notebook, we won't execute anything remotely. Instead we'll just cover some basic abstractions provided by the library.
We start with the abstractions of the resources (machines and networks that are usually given by an infrastructure)
We start with the abstractions of resources (machines and networks that are usually given by an infrastructure)
### Host
### Host
An host is anything we can connect to and act on. Most of the time it corresponds to a machine reachable through SSH.
An host is anything we can connect to and act on. Most of the time it corresponds to a machine reachable through SSH.
The datastructure reflects this.
The datastructure reflects this.
Usually you don't instantiate hosts manually, instead they are brought to you by EnOSlib (because most likely they depend on a scheduler decision like OAR on Grid'5000).
Usually you don't instantiate hosts manually, instead they are brought to you by EnOSlib (because most likely they depend on a scheduler decision like OAR on Grid'5000).
The local machine can be represented by an instance of the `LocalHost` object. This is a specialization of an `Host`, the connection to this host will be made using sub-processes (instead of SSH). We can see it in the `extra` attribute of the `LocalHost` object. This `extra` attribute is actually interpreted when a "remote" action is triggered on our hosts.
The local machine can be represented by an instance of the `LocalHost` object. This is a specialization of an `Host`, the connection to this host will be made using sub-processes (instead of SSH). We can see it in the `extra` attribute of the `LocalHost` object. This `extra` attribute is actually interpreted when a "remote" action is triggered on our hosts.
Other types of Hosts are possible. The library has a `DockerHost` which represents a docker container we want to reach using the docker TCP protocol. One needs to specify where this container is running by passing an host instance.
Other types of Hosts are possible. The library has a `DockerHost` which represents a docker container we want to reach using the docker TCP protocol. One needs to specify where this container is running by passing an host instance.
The above `extra` field suggest that the connection to this docker container will be made through an ssh jump to the remote host hosting the container.
The above `extra` field suggest that the connection to this docker container will be made through an ssh jump to the remote host hosting the container.
This will be done transparently by the library anyway.
This will be done transparently by the library anyway.
---
---
%% Cell type:markdown id:exceptional-techno tags:
%% Cell type:markdown id:exceptional-techno tags:
### Roles
### Roles
%% Cell type:markdown id:tight-request tags:
%% Cell type:markdown id:tight-request tags:
A common pratice when experimenting, especially with distributed applications, is to form logical group of machines.
A common pratice when experimenting, especially with distributed applications, is to form logical group of machines.
Indeed, during an experiment your hosts will serve different purposes: some will host the system you are studying while other will install third party tools to inject some load, observe ...
Indeed, during an experiment your hosts will serve different purposes: some will host the system you are studying while other will install third party tools to inject some load, observe ...
A natural way of configuring differently several sets of hosts is to tag them and group them according to their tags.
A natural way of configuring differently several sets of hosts is to tag them and group them according to their tags.
The `Roles` datastructure serves this purpose: it lets you group your hosts based on tags. It follow a `dict-like` interface.
The `Roles` datastructure serves this purpose: it lets you group your hosts based on tags. It follow a `dict-like` interface.
%% Cell type:code id:spatial-probe tags:
%% Cell type:code id:spatial-probe tags:
``` python
``` python
h1=en.Host("10.0.0.1")
h1=en.Host("10.0.0.1")
h2=en.Host("10.0.0.2")
h2=en.Host("10.0.0.2")
h3=en.Host("10.0.0.3")
h3=en.Host("10.0.0.3")
roles=en.Roles()
roles=en.Roles()
roles["tag1"]=[h1,h2]
roles["tag1"]=[h1,h2]
roles["tag2"]=[h3]
roles["tag2"]=[h3]
roles["tag3"]=[h2,h3]
roles["tag3"]=[h2,h3]
roles
roles
```
```
%% Cell type:markdown id:adapted-apparatus tags:
%% Cell type:markdown id:adapted-apparatus tags:
### Network and Networks
### Network and Networks
`Network` and `Networks` are the same as `Host` and `Roles` but for networks:
`Network` and `Networks` are the same as `Host` and `Roles` but for networks:
-`Network` represent a single Network
-`Network` represent a single Network
-`Networks` represent a "Roles" of Network: networks indexed by their tags
-`Networks` represent a "Roles" of Network: networks indexed by their tags
.
.
Networks are usually given by an infrastructure and thus you won't really instantiate `Network` nor `Networks` by yourself.
Networks are usually given by an infrastructure and thus you won't really instantiate `Network` nor `Networks` by yourself.
More precisely there exists a specific subclass of `Network` per infrastructure which will be returned automatically by EnOSlib when needed.
More precisely there exists a specific subclass of `Network` per infrastructure which will be returned automatically by EnOSlib when needed.
Moreover `Network` datastructure isn't exposed in EnOSlib at the top level, let's see however how a `DefaultNetwork` can look like. A `DefaultNetwork` is a very common abstraction of a network that allows to represent a basic network with optionnally a pool of free ips/macs address. For instance a subnet or a vlan on Grid5000 are represented by a specific `DefaultNetwork`.
Moreover `Network` datastructure isn't exposed in EnOSlib at the top level, let's see however how a `DefaultNetwork` can look like. A `DefaultNetwork` is a very common abstraction of a network that allows to represent a basic network with optionnally a pool of free ips/macs address. For instance a subnet or a vlan on Grid5000 are represented by a specific `DefaultNetwork`.
A `Provider` must be fed with a `Configuration`. `Configuration` objects are specific to each provider.
A `Provider` must be fed with a `Configuration`. `Configuration` objects are specific to each provider.
You can build them from a dictionnary (e.g from a yaml/json file) or programmatically. For instance the schema for Grid'5000 is [here](https://discovery.gitlabpages.inria.fr/enoslib/apidoc/infra.html#g5k-schema).
You can build them from a dictionnary (e.g from a yaml/json file) or programmatically. For instance the schema for Grid'5000 is [here](https://discovery.gitlabpages.inria.fr/enoslib/apidoc/infra.html#g5k-schema).
In this section, we'll only build some configurations (No resource will be reserved on Grid'5000)
In this section, we'll only build some configurations (No resource will be reserved on Grid'5000)
- Many configurations options are possible. [The documentation](https://discovery.gitlabpages.inria.fr/enoslib/tutorials/grid5000.html) will show you some more.
- Many configurations options are possible. [The documentation](https://discovery.gitlabpages.inria.fr/enoslib/tutorials/grid5000.html) will show you some more.
- In EnOSlib `Roles` and `Networks` don't really depend on the provider that produced them. In other words you can substitute one provider's configuration to another one easily without changing the artifact code.
- In EnOSlib `Roles` and `Networks` don't really depend on the provider that produced them. In other words you can substitute one provider's configuration to another one easily without changing the artifact code.
