-
Notifications
You must be signed in to change notification settings - Fork 31
Configure LNST
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. However, you still cannot use the same option more than once in the same configuration file.
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.
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.
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
machine_pool_dirs =
test_tool_dirs = ./test_tools
test_module_dirs = ./test_modules
log_dir = ./Logs
resource_dir =TODO
At the moment we are only using the [environment] section but we might be adding more options and sections later. It 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.
- machine_pool_dirs accepts a list of directories that are to be searched during the Machine Pool initialization. The directories need to be separated by white-spaces.
- 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.
The default slave configuration looks something like this:
[cache]
cache_dir = ./cache
expiration_period = 7days
[environment]
log_dir = ./Logs
use_nm = yesThe 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]]whereXis any integer.
The section [environment] at the moment contains only two 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
yesortruethe slave will useNetworkManagerfor configuration and management of test network interfaces otherwise if the value isnoorfalsethenlnstwill fallback to command line tools likeip,brctletc.; if Network Manager is not detected on the slave this option is ignored and behaves as it has been set tono