Understanding the Pipeline - an administrator guide


Administrators who are familiar with the terminology of the pipeline and templates can skip this section. If so, move on to Requirements for a LAVA device.

Device type templates

Device type templates exist on the master in the /etc/lava-server/dispatcher-config/device-types/ directory.

Although the example templates include jinja markup, the template itself is YAML. The files use the .jinja2 filename extension to make it easier for editors to pick up the correct syntax highlighting, but whatever jinja does not recognise is passed through unchanged. The output of rendering the template must always be valid YAML.

If you are starting with just a single device of the relevant device type on a particular instance, you don’t need to include jinja markup in the device type template - it can stay as YAML. Once you have more than one device or you are considering contributing the template upstream, then you will need to support the jinja markup. Jinja is used to:

  • avoid code duplication - e.g. if a U-Boot command stanza is common to a number of device types (it does not have to be all devices capable of supporting U-Boot), then the common code needs to move into the base template and be inserted using jinja.
  • support multiple devices - e.g. if the configuration needs serial numbers (for adb) or references to unique IDs (like UUID of storage devices) or IP addresses (for primary ssh connections) then these can be set as defaults in the template but need a variable name which is then overridden by the device dictionary.
  • support job-level overrides - if a variable exists in the device type template and that variable is not set in the device dictionary, it becomes available for the job submission to set that variable.

Device dictionary

The device dictionary is a file. In the early stages, it can be very simple:

{% extends 'mytemplate.jinja2' %}

Comments may be used in device dictionary files, using the jinja syntax:

{# comment goes here #}

To remove a variable from a device dictionary, simply remove or comment out the variable in the file.

It is recommended to keep device dictionary files in version control of some kind to make it easier to track changes. The administrative interface tracks when and who changed the device dictionary but not the detail of what was changed within it.

See also

Using XML-RPC and Using the command line for information on how to use the new file to update the device dictionary. (Needs superuser permissions on that instance.)

The Jinja template documentation gives more information on jinja syntax, although the examples are for HTML. Not all features of the jinja template API can be supported in a device dictionary or device type template. All of the logic within the template support, such as conditionals and the use of blocks, is only to be done in the device type template.

Checking your templates

Whenever you modify a device type template, take care to respect the indentation within the file. You can (temporarily) copy your template into lava_scheduler_app/tests/device-types and run the unit tests to verify that the template can be parsed and rendered as valid YAML:

$ ./lava_server/manage.py test lava_scheduler_app.tests.test_device.DeviceTypeTest

(As with all unit tests in lava-server, this requires that lava-server is installed and configured on the machine running the test and that the version of lava-server is recent enough such that its database schema is compatible with the source code in the git checkout you are using. It does not need to be latest, as long as it is consistent with the version installed. If you are using production releases or jessie-backports, this is likely to mean using git pull; git checkout release.)

All contributions are required to pass this test (amongst others) and you will not be able to successfully run jobs through your instance if it fails.

Finally, although the final configuration sent to the dispatcher will be stripped of comments, it is strongly recommended to use comments liberally in all your YAML files, including device type templates.

Finding your way around the files

  • Start with a device-type YAML file from the dispatcher which is similar to the one you want to support. Modify the YAML and verify using the Online YAML parser to make sure you always have valid YAML. This is the basis of your device type template. Use comments liberally, this is YAML remember.
  • Compare that with the device-specific YAML which is what the dispatcher will actually see. Again, modify the YAML and verify using the Online YAML parser and make sure you always have valid YAML. This is what your device type template will need to produce.
  • Identify variables which are device-specific and add comments about what will need to be handled when the device type template is used.
  • Create a minimal device dictionary file which simply extends your initial device type template.

Information sources

The pipeline tests repository

This git repository holds working examples of a range of different jobs for a range of different devices. These jobs are routinely submitted as functional tests of upcoming releases of the LAVA software.


Not every combination of deployment method or boot method can be expressed for all supported devices but we aim to have at least one example of each deployment method and each boot method on at least one supported device.

Check the standard directory for tests which use gold standard images.

The lava-dispatcher pipeline source code

As well as the source code, the devices and device_types directories in this git repository contain YAML examples of device and device type configuration. These are the raw forms which are used on the lava-dispatch command line and are useful for debugging and starting to create support for your own devices.


The lava-server unit test support

The Jinja2 device-type templates here are used for the unit tests and also become the default device type templates when the packages are built. The devices directory contains working device dictionary examples for these device types.


Extra device configuration

There are a variety of optional elements of device configuration which need to be considered at an administrator level.

Providing permanent IPv4 addresses

Not all devices of one device-type will necessarily need fixed IPv4 addresses to be configured in the device dictionary. Admins should consider the use of :term`device tags`.

Providing temporary filesystem storage

lava-target-storage - Where devices have alternative storage media fitted, the id of the block device can be exported. For example, this can help provide temporary storage on the device when the test shell is running a ramdisk or NFS. Some devices may provide a USB mass storage device which could also be exported in this way.

Test writers need to be able to rely on getting a known block device, without complications from enumeration at boot. If a second block device is desired, the method label could simply append a unique ID, SATA-1, SATA-2 etc.

Only a single block device is supported per method. The method itself is simply a label specified by the admin. Often it will relate to the interface used by the block device, e.g. SATA or USB but it could be any string. In the example below, UMS is the label used by the device (as an abbreviation for USB Mass Storage).


Do not specify the ID for a partition as this will change if a test changes the partition table. There must be no files on the exported block device which are necessary for the device to reboot and execute another test job successfully. Not all devices can support such temporary storage.

Extra dispatcher configuration

It is possible to supply dispatcher-specific configuration along with each test job, using the support in /etc/lava-server/dispatcher.d/. The master will read files in this directory which match the hostname of a known worker and send the configuration to that worker.

An example file exists in /usr/share/lava-dispatcher/dispatcher.yaml on each worker.

Current support includes:

  • Sets the dispatcher_ip, if the dispatcher has many IPs
# Only set this key, if this dispatcher has many IPs
#dispatcher_ip: <this-dispatcher-ip>
  • Sets the container creation path.
# Set this key, if you want to change the default lxc creation path
# No trailing /
# The default path is /var/lib/lxc
#lxc_path: <custom-path>

Requirements for a LAVA device

The new design makes less assumptions about the software support on the device - principally only a working bootloader is required. The detail of working includes but is not restricted to:

Hardware Requirements

  • Serial - the principle method for connecting to any device during an automated test is serial. If a specific baud rate or particular UART connections are required, these must be declared clearly.
  • Network - tests will need a method for delivering files to the device using the bootloader. Unless the bootloader has full support for wireless connections, physical ethernet is required.
  • Power - automation requires that the board can be reliably reset by removing and then reapplying power. The board must support this in an automatic manner, without needing human intervention to press a reset button or similar. If such a button is present, each device will need to be modified to remove that barrier.

Software Requirements

  • Interruptable - for example, uBoot must be configured to emit a recognisable message and wait for a sufficient number of seconds for a keyboard interrupt to get to a prompt.
  • Network aware - most common deployments will need to pull files over a network using TFTP.
  • Stable - the bootloader is the rescue system for the device and needs to be reliable - if the test causes a kernel panic or hardware lockup, resetting the board (by withdrawing and re-applying power) must always put the board back to the same bootloader operation as a standard power-on from cold. Note that USB serial connections can be a particular problem by allowing the device to continue to receive some power when the power supply itself is disconnected.
  • Configurable - the bootloader needs to be configured over the serial connection during a test. Such configuration support needs to be robust and not lock up the device in case of invalid user input.
  • Accessible - the bootloader will need to be updated by lab admins from time to time and this should be as trivial as possible, e.g. by simply copying a binary to a known location using an established protocol, not some board-specific routine requiring special software.
  • Flexible - the bootloader should support as wide a range of deployments as possible, without needing changes to the bootloader itself. e.g. only having support for uncompressed kernel images would be a problem.

With such a bootloader installed on the device, the test writer has a wide range of possible deployments and boot methods.

Adding support for a device of a known type


Not all devices supported by the old dispatcher are currently supported in the pipeline. The configuration for the old dispatcher is very different to pipeline support - the intrinsic data of load addresses and ports remains but the layout has changed.

A known device type for the pipeline means that a template file exists in /etc/lava-server/dispatcher-config/device-types/.

This is a Jinja2 template which is turned into a complete YAML file when a job needs to run on the device using settings in the device dictionary. Initially, you can work with a static YAML file and deal with how to use the template and the dictionary later.

If this is the first device you are adding to this instance or the first device using a new remote worker, this will need to be configured first. The device type and a Device entry using that type will need to be created in the database. Once the device dictionary is working, the device can be marked as a pipeline device in the admin interface. See Creating a new device entry for a known device type.

Obtaining configuration of a known device

The simplest way to start is to download the working configuration of a device of the same known device type using XML-RPC or the lava-tool device-dictionary command, see lava-tool (1). This will (by default) write a new file in the current working directory containing the configuration.

This YAML file will then need some tweaks for your local setup. e.g. these values will differ for every local LAVA instance.

   connect: telnet playgroundmaster 7018
   hard_reset: /usr/bin/pduclient --daemon services --hostname pdu09 --command reboot --port 04
   power_off: /usr/bin/pduclient --daemon services --hostname pdu09 --command off --port 04
   power_on: /usr/bin/pduclient --daemon services --hostname pdu09 --command on --port 04

See also

Power Commands

These values are similar to the existing dispatcher configuration and those values can be transferred directly into the new structure.

With this local YAML file, you can now run pipeline jobs on that device but only from the lava-dispatch command line:

$ sudo lava-dispatch --target ./bbb01.yaml bbb-ramdisk.yaml --output-dir=/tmp/test/


unlike the current dispatcher, the pipeline dispatcher takes a complete YAML file, with path, as the target. There is no default location for this file - in routine usage, the dispatcher has no permanent configuration for any pipeline device - the YAML is delivered to the dispatcher at the start of each job, generated from the device dictionary and the template.

A sample pipeline testjob definition can be downloaded from the same instance as you obtained the device configuration.

lava-tool can also compare the device configuration YAML files using the compare_device_conf option (see also Creating a device dictionary for the device.) The output is a unified diff of the two YAML files:

$ lava-tool compare-device-conf ./black02.yaml ./pipeline/devices/black01.yaml
--- /home/neil/black02.yaml
+++ /home/neil/pipeline/devices/black01.yaml

@@ -1,5 +1,5 @@

-    connect: telnet localhost 6001
+    connect: telnet localhost 6000

 device_type: beaglebone-black

The unified diff can also be piped to wdiff -d to show as a word diff:

lava-tool compare-device-conf ./black02.yaml ./pipeline/devices/black01.yaml|wdiff -d

[--- /home/neil/black02.yaml-]
{+++ /home/neil/pipeline/devices/black01.yaml+}

@@ -1,5 +1,5 @@

    connect: telnet localhost [-6001-] {+6000+}

device_type: beaglebone-black


Unlike the current dispatcher, the pipeline does not care about the hostname of the device, the name of the file is unrelated and nothing about the job needs to know anything about the hostname (the MultiNode API has support for making this information available to the test cases via the scheduler).

Creating a new device entry for a known device type

If this device does not already exist in the database of the instance, it will need to be created by the admins. This step is similar to how devices were added to the database with the current dispatcher:

  • Login to the Adminstration interface for the instance
  • Click on Lava_Scheduler_App

If there are no devices of this device type in the instance, check that the device type exists and create it if not. Don’t worry about a health check at this stage. (pipeline device health checks will follow in time.)

Create the device using the device type and ensure that the device has the Pipeline device? field checked. Pipeline devices need the worker hostname to be set manually in the database, ensure this is correct, then save the changes.

Creating a device dictionary for the device

See also

Updating a device dictionary to add a device dictionary to a new pipeline device.

Existing devices

Export the device dictionary of existing devices in the original jinja2 syntax, ready for modification.

The local YAML file downloaded using get-pipeline-device-config, whether XML-RPC or lava-tool is the result of combining a device dictionary and the Jinja2 template. To be able to submit and schedule jobs on the device, the values from your modified file need to be entered into the database of the instance you want to use to schedule the jobs. These values are stored as a device dictionary.

Compare with the existing device dictionary for the device. (If you do not have access, ask the admins for an export of the dictionary):

$ lava-tool device-dictionary SERVER HOSTNAME --export > file.jinja2


the device dictionary can have a variety of values, according to the support available in the template specified in the extends setting. There is no mention of the hostname within the exported dictionary.

Now modify the dictionary (Jinja2 child template format) to set the values required:

{% extends 'beaglebone-black.jinja2' %}
{% set power_off_command = '/usr/bin/pduclient --daemon services --hostname pdu09 --command off --port 04' %}
{% set hard_reset_command = '/usr/bin/pduclient --daemon services --hostname pdu09 --command reboot --port 04' %}
{% set connection_list = [‘uart0’] %}
{% set connection_commands = {‘uart0’: ‘telnet playgroundmaster 7018’} %}
{% set connection_tags = {‘uart0’: [‘primary’, 'telnet']} %}
{% set power_on_command = '/usr/bin/pduclient --daemon services --hostname pdu09 --command on --port 04' %}


LAVA does not preserve history of a device dictionary, it is recommended that the files used to create the dictionaries are kept under version control.

Viewing current device dictionary content

The admin interface displays the current device dictionary contents in the Advanced Properties drop-down section of the Device detail view. e.g. for a device called kvm01, the URL in the admin interface would be /admin/lava_scheduler_app/device/kvm01/, click Show on the Advanced Properties section.

The Advanced Properties includes the device description and the device tags as well as showing both the YAML formatting as it will be sent to the dispatcher and the Jinja2 formatting used to update the device dictionary.


The device dictionary is not editable in the Django admin interface due to constraints of the key value store and the django admin forms. The device configuration for pipeline devices is managed using external files, allowing version control of the device configuration.

Updating a device dictionary

The populated dictionary now needs to be updated on the filesystem of the instance.

All operations to update a device dictionary need to be done by a superuser. The specified device must already exist in the database and be marked as a pipeline device for the dictionary to be active -

Using lava-tool


Ensure you update to the latest version of lava_tool (>= 0.23) to use the device-dictionary --update and --export functions as superuser.

$ lava-tool device-dictionary SERVER HOSTNAME --export > file.jinja2
Please enter password for encrypted keyring:

The filename and extension are completely arbitrary but you may find that your preferred editor has highlighting support for jinja2. The contents of the file can be something like:

{% extends 'beaglebone-black.jinja2' %}
{% set power_off_command = '/usr/bin/pduclient --daemon localhost --hostname pdu01 --command off --port 12' %}
{% set hard_reset_command = '/usr/bin/pduclient --daemon localhost --hostname pdu01 --command reboot --port 12' %}
{% set connection_command = 'telnet dispatcher01 7001' %}
{% set power_on_command = '/usr/bin/pduclient --daemon localhost --hostname pdu01 --command on --port 12' %}

Make changes within the Jinja2 child template syntax and then lava-tool can be used to update a new device dictionary (replacing the previous device dictionary):

$ lava-tool device-dictionary SERVER HOSTNAME --update file.jinja2
Please enter password for encrypted keyring:
Device dictionary updated for black01


Superusers can use import_device_dictionary to update a Jinja2 string for a specified Device hostname:

# Python3
import xmlrpc.client
username = "USERNAME"
token = "TOKEN_STRING"
hostname = "HOSTNAME"
protocol = "PROTOCOL"  # http or preferably https
server = xmlrpc.client.ServerProxy("%s://%s:%s@%s/RPC2" % (protocol, username, token, hostname))
server.scheduler.import_device_dictionary(device_hostname, jinja_string)

If the dictionary did not exist for this hostname, it will be created. The XML-RPC call will return:

Adding new device dictionary for black01

The dictionary is then updated. If the file is valid, the XML-RPC call will return:

Device dictionary updated for black01

Superusers can also export the existing jinja2 device information using export_device_dictionary for a known device hostname. This output can then be edited and used to update the device dictionary information.

Using the command line

The device dictionary exists as a jinja2 file in /etc/lava-server/dispatcher-config/devices and can be updated by admins with the necessary access.