LAVA V2 is available in Debian unstable, stretch and jessie-backports: lava-server.

LAVA

LAVA is a continuous integration system for deploying operating systems onto physical and virtual hardware for running tests. Tests can be simple boot testing, bootloader testing and system level testing. Extra hardware may be required for some system tests. Results are tracked over time and data can be exported for further analysis.

LAVA has a long history of supporting continuous integration of the Linux kernel on ARM devices (ARMv7 & ARMv8). So if you are testing a Linux kernel image on armhf or arm64 devices, you will find a lot of similar tests already running on the other LAVA instances.

This page exists as a supplement to the LAVA documentation, to outline where the Debian instance differs from other LAVA instances. If this page and the packaged documentation disagree, the packaged documentation is correct. Where errors exist or where the documentation is unclear, please file bugs, submit patches and generally let us know. Bugs can be filed in the Debian BTS against lava-server or lava-dispatcher or in the upstream bugtracker linked from the bottom of each page of the UI, whichever you prefer.

Linaro Cambridge lab

http://validation.linaro.org

This is the master instance for Linaro. To use devices on this instance, community members can register with Linaro

http://staging.validation.linaro.org

This is the test instance for the LAVA software team, generally running release candidates for the next upstream release of the LAVA packages.

Collabora

https://lava.collabora.co.uk/

Deprecated Distributed Deployment support

The former content of this page relates to the deprecated installation methods and submission formats. This content is now at Deprecated Distributed Deployment support and has particular information related to the Collabora instance.

Developer instances

https://lava.codehelp.co.uk/

This is a developer playground instance, used for deployment of some of the new devices being added to LAVA.

Requirements for a LAVA device

Particular types of device will have different details in the device dictionary. For example, a QEMU device will want to limit the amount of memory allocated and a beaglebone-black device will need a connection command to allow the slave to connect to the serial console over a USB FTDI connection. Documentation exists in the lava-server-doc package with examples of the dictionaries of known devices.

Different developers will be able to offer different levels of service, depending on the hardware configuration of their local lab. In particular, not all developers will be able to offer devices on a 24/7 basis as this requires some custom hardware, like a PDU.

Example for a panda device

This is an example of a device available on the Debian LAVA instance. This device is attached to a slave which is permanently available and the device is configured in LAVA to provide access to PDU control.

{% extends 'panda.yaml' %}
{% set exclusive = 'True' %}
{% set hard_reset_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command reboot --port 07' %}
{% set power_off_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command off --port 07' %}
{% set connection_command = 'telnet droopy 4003' %}
{% set power_on_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command on --port 07' %}

This is the Jinja format of the data visible in the UI. Only superusers can export or update this data directly from the database.

Questions

There are a number of issues and questions which come to mind when considering how to offer devices to a service like LAVA. Please contact NeilWilliams and use the LAVA support mailing lists.

LAVA V1 and V2

LAVA is has now completed the lengthy migration from V1 to the pipeline V2 model. All devices must now support V2 and all support for V1 has ceased. 2017.11-1 removes visibility of the V1 support and removes the V1 lava-dispatcher codebase. 2017.12 will remove V1 test data from the database.