-
Notifications
You must be signed in to change notification settings - Fork 32
Set up Your Machine Pool
In this document, we will explain how to set up your own test lab with LNST and how to start using it for executing your tests. LNST uses machine pools for organizing machines available for testing, you can have several of these, normally you would represent a physical test lab with a separate machine pool. In this document we will walk you through creating such a machine pool from a single test lab.
Suppose we have the following lab configuration that we want to set up for LNST:
+-----------+ +-----------+ +-----------+
| Machine 1 | | Machine 2 | | Machine 3 |
+-----------+ +-----------+ +-----------+
| | |
A | B | C |
| | |
| +-----------+ |
+----------------| Machine 4 |----------------+
+-----------+
| | |
D | D | D |
| | |
+-----------+ D +-----------+
+----------------| Switch |----------| Machine 5 |
| +-----------+ +-----------+
D | | |
| D | | D
| +--+ +-------------------+
| | |
+-----------+ +-----------+ +-----------+
| Machine 6 | | Machine 7 | | Machine 8 |
+-----------+ +-----------+ +-----------+
There are eight (1-8) machines, one non-managed switch and four (A-D) L2 network segments. We will use this example to guide you through the whole process.
To set up a test lab for use in LNST, you need to create a pool directory for your lab. This directory will contain configuration of all the machines in your lab. One machine per-file.
For our example we will create a directory called lab and populate it with
one XML file for each machine. These files will contain machine
configurations. The switch in the lab is not managed, so there will be no
configuration for it in the pool.
$ cd lab/
~/lab $ ls -1
machine1.xml
machine2.xml
machine3.xml
machine4.xml
machine5.xml
machine6.xml
machine7.xml
machine8.xmlThese XML files contain a root slavemachine tag of the respective machine, under which you describe the parameter of the machine and available interfaces. Here's an example configuration for machines 1 and 4:
<slavemachine>
<params>
<param name="hostname" value="192.168.100.10"/>
<param name="rpc_port" value="9999"/>
</params>
<interfaces>
<eth label="A" id="1">
<params>
<param name="hwaddr" value="52:54:00:a7:32:15"/>
</params>
</eth>
</interfaces>
</slavemachine><slavemachine>
<params>
<param name="hostname" value="192.168.100.1"/>
</params>
<interfaces>
<eth id="1" label="A">
<params>
<param name="hwaddr" value="52:54:00:e4:75:16"/>
</params>
</eth>
<eth id="2" label="B">
<params>
<param name="hwaddr" value="52:54:00:91:01:9c"/>
</params>
</eth>
<eth id="3" label="C">
<params>
<param name="hwaddr" value="52:54:00:94:b7:32"/>
</params>
</eth>
<eth id="4" label="D">
<params>
<param name="hwaddr" value="52:54:00:f3:a1:2a"/>
</params>
</eth>
<eth id="5" label="D">
<params>
<param name="hwaddr" value="52:54:00:12:eb:07"/>
</params>
</eth>
<eth id="6" label="D">
<params>
<param name="hwaddr" value="52:54:00:78:dd:42"/>
</params>
</eth>
</interfaces>
</slavemachine>As you can see, there are two sections in a slavemachine config. The first
section, <params>, contains information about the machine itself, e.g. IP
address or hostname, and any additonal information that can describe the
machine. The parameter names are completely arbitrary and you specify any
information you deem useful, the only required parameter is the
hostname parameter, which will be used to connect to the slave machine.
The other section contains information about physical devices that are
available for testing. Each device must have a unique (with regards to the
<interfaces> tag) ID string assigned (the id attribute). This is used by
LNST for further reference to the device. Another important attribute is
label, this attribute is mandatory. It gives the controller information
about how the machines within the lab are connected to each other (interfaces
that are on the same L2 network have the same label). It is then used to
construct the lab topology. And finally as you can see from the example you can
define additional parameters for the interfaces. The same rules apply about
arbitrary names, only now the required parameter is hwaddr that is used
to look up the interface on the slave machine.
When you have your pool directory set up and ready, you need to point LNST to
its location. This is done in the configuration file in
~/.lnst/lnst-ctl.conf. Here is an example of how it usually looks:
[environment]
mac_pool_range = 52:54:01:00:00:01 52:54:01:FF:FF:FF
rpcport = 9999
test_tool_dirs += ./test_tools
test_module_dirs += ./test_modules
log_dir = ./Logs
[pools]
pool = ~/.lnst/poolAll you need to do is to add a new pool to the [pools] section.
[pools]
pool = ~/.lnst/pool
my_lab = ~/labIf the file doesn't exist you can create it and specify just the [pools] section, everything else will use the default values.
When you have a working lab already set up to work with LNST, you can proceed directly to testing. The machine pools defined in your configuration files will be used automatically. LNST will also automatically check if the slave machines are available (lnst-slave is running and it's not used by a different controller), after that it will try to match your recipe with the available machines and inform about the chosen machines. Finally the recipe will be executed.
To learn how to write your own recipe read this page.