Skip to content

Configure LNST

Jump to bottom
Ondrej Lichtner edited this page Oct 25, 2016 · 12 revisions

You can change the configuration of LNST by changing the values located in the files lnst-ctl.conf (to configure the controller) and lnst-slave.conf (to configure the slave). The file format is a slightly extended .ini, so it should look familiar. The difference is that some options accept more than one value, in those cases the values are separated by at least one white-space. If you need to use a white-space as part of the value use '\' as an escape character.

Another difference is that we allow the use of '+=' operator in addition to '=' for options that accept a list of directories. With this you can add new values to the list of values that were loaded from previous configuration files.

1. Location of configuration files

Configuration files can be located in several locations depending on your setup. The controller application uses these locations:

  • /etc/lnst-ctl.conf this file contains system-wide configuration values and it should be created during installation from the package.
  • ./lnst-ctl.conf the location of this file is relative to the lnst-ctl script location. If it is discovered, it is used instead of the system-wide configuration. This is useful if you just want to try LNST without installing it.
  • ~/.lnst/lnst-ctl.conf this file contains the user-specific configuration. It is created automatically when you first start the application. This should be the first file to look at if you want to configure something. It is the last to be parsed and therefore can override options set in the previous two files.
  • -c FILE_PATH additionally you can use the -c option when launching lnst-ctl to make the controller load a third additional file. This file will be loaded last, after the standard locations have been read.
  • -C FILE_PATH finally you can use the -C option when launching lnst-ctl to make the controller reset the internal config state to the default and load the specified config file. This is useful when you want to ignore the system-wide or user-specific configuration files.

The slave application uses these two locations:

  • ./lnst-slave.conf relative to the location of the lnst-slave script if you are using LNST without installation, or
  • /etc/lnst-slave.conf if you have LNST installed on your machine.

The slave does not have any user specific configuration file as it should always be running with root privileges. These files are mutually exclusive so only one of them will be loaded.

2. Controller configuration

Controller configuration will be explained using the default configuration file:

[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
resource_dir =
allow_virtual = false

[pools]

[perfrepo]
url =
username =
password =

[security]
identity =
privkey =

[colour]

This page will only cover sections [environment], [pools] and [perfrepo], sections [security] and [colour] are covered in their own web pages: Security and Colouring.

Environment

The environment section contains these options:

  • mac_pool_range accepts values in the format:"<start_address> <end_address>", both addresses have to be specified and be in a valid MAC address format; they are separated using a space but you can use any white-space character you like.
  • rpcport accepts a single integer. It is used as the default port on which we assume the slaves are accepting RPC connections. This can always be overridden by specifying a different port directly in the recipe file.
  • test_tool_dirs accepts a list of directories separated by white-spaces as well. These directories will be searched for test tools that you can use in your recipes.
  • test_module_dirs again accepts a list of directories separated by white-spaces. These directories will be searched when looking up test modules.
  • log_dir option can be used to redirect where the logs should be written. The accepted value is a directory path, the directory will be created if it doesn't exist yet.
  • resource_dir option specifies, where are the generic resources for LNST (such as XML schemas) installed. This option is set during the installation and generally doesn't need to be changed (unless you know what you're doing!).
  • allow_virtual option accepts a boolean value which controlls whether or not the LNST controller is allowed to match against virtual configurations where the network topology will be created dynamically through libvirt.

Pools

The pools section accepts any number of options in of the following format:

  • pool_name = path/to/pool/dir where pool_name is any name you want to give to a pool (can be different from the directory name), this will be used by LNST to refer to the pool in the Logs. And path/to/pool/dir is a valid path to a directory containing slave description files. If you specify the same pool_name more than once, you will overwrite the previous definition.

PerfRepo

The PerfRepo section contains the following options:

  • url accepts an http link to a PerfRepo instance where you want to store your performance results
  • username accepts the username which will be used when authenticating to the PerfRepo instance
  • password accepts the password which will be used when authenticating to the PerfRepo instance

By default this section is commented out which disables any PerfRepo integration in LNST. All recipes with PerfRepo support will just work, ignoring all the PerfRepo related commands.

3. Slave configuration

The default slave configuration looks something like this:

[environment]
log_dir = ./Logs
use_nm = yes
rpcport = 9999

[cache]
cache_dir = ./cache
expiration_period = 7days

[security]
auth_types =
auth_password =
privkey =
ctl_pubkeys =

[colour]

The [security] section is covered in here.

The slave application sometimes needs to receive files from the controller. These are mostly test modules and test tools that can often change versions. Transferring them manually would be tedious. For this reason the transfer is done automatically and the files are stored in the slaves cache. You can configure the cache with options in the [cache] section:

  • cache_dir specifies the directory where the cache should be located, the directory is created if it doesn't exist.
  • expiration_period defines how long after the last use of a specific file we keep it. After that period it is deleted on the next test run. Accepted format is: [Xday[s]] [Xhour[s]] [Xminute[s]] [Xsecond[s]] where X is any integer.

The section [environment] at the moment contains only three options and these are:

  • log_dir accepts a directory path where the logs will be stored. If the directory doesn't exist it will be created.
  • use_nm if set to yes or true the slave will use NetworkManager for configuration and management of test network interfaces otherwise if the value is no or false then lnst will fallback to command line tools like ip, brctl etc.; if Network Manager is not detected on the slave this option is ignored and behaves as it has been set to no
  • rpcport that tells the server application on which port to listen for connections

Finally slaves also accept colouring of terminal output, that can be configured with the [colour] section described here.

Clone this wiki locally