[ Help Overview] [ Help V1] [ Home ] [ Results ] [ Scheduler ] [ API ]
LAVA V2 is the second major version of LAVA. The major user-visible features are:
The architecture has been significantly improved since V1, bringing major changes in terms of how a distributed LAVA instance is installed, configured and used for running test jobs.
Migration to V2 started with the 2016.2 release.
LAVA is the Linaro Automation and Validation Architecture.
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, although extra hardware may be required for some system tests. Results are tracked over time and data can be exported for further analysis.
LAVA is a collection of participating components in an evolving architecture. LAVA aims to make systematic, automatic and manual quality control more approachable for projects of all sizes.
LAVA is designed for validation during development - testing whether the code that engineers are producing “works”, in whatever sense that means. Depending on context, this could be many things, for example:
LAVA is good for automated validation. LAVA tests the Linux kernel on a range of supported boards every day. LAVA tests proposed android changes in gerrit before they are landed, and does the same for other projects like gcc. Linaro runs a central validation lab in Cambridge, containing racks full of computers supplied by Linaro members and the necessary infrastucture to control them (servers, serial console servers, network switches etc.)
LAVA is good for providing developers with the ability to run customised test on a variety of different types of hardware, some of which may be difficult to obtain or integrate. Although LAVA has support for emulation (based on QEMU), LAVA is best at providing test support for real hardware devices.
LAVA is principally aimed at testing changes made by developers across multiple hardware platforms to aid portability and encourage multi-platform development. Systems which are already platform independent or which have been optimised for production may not necessarily be able to be tested in LAVA or may provide no overall gain.
Note
This overview document explains LAVA using
http://validation.linaro.org/ which is the official
production instance of LAVA hosted by Linaro. Where examples
reference validation.linaro.org
, replace with the fully
qualified domain name of your LAVA instance.
See also
Continuous Integration which covers how LAVA relates to continuous integration (CI) and covers the consequences of what LAVA can and cannot do with particular emphasis on how automation itself can block some forms of testing.
LAVA installations consist of two primary components - a master and a worker. The master has all the code required to run a worker and can support multiple remote workers to increase the number of devices available on any one instance.
lava-dispatch
process, started by the
lava-slave
when instructed to do so by the master. This process
manages all the operations on the device under test, according to the
job submission and device parameters sent by the master.All test jobs involve a deployment step of some kind, even if that is just to prepare the overlay used to copy the test scripts onto the device or to setup the process of parsing the results when the test job starts.
Hardware devices need to be instructed how to boot, emulated devices need
to boot the emulator. For other devices, a boot
can be simply establishing
a connection to the device.
The principal test method in LAVA is the Lava Test Shell which requires a POSIX type environment to be running on the booted device. Other test methods available include executing tests using ADB.
Some test jobs need to boot up multiple devices in a single, coordinated, group. For example, a server could be tested against multiple clients. LAVA supports starting these sub jobs as a group as well as passing messages between nodes via the dispatcher connection, without needing the devices to have a working network stack.
LAVA has advanced support for scheduling multiple jobs across multiple devices, whether those jobs use one device or several. Scheduling is ordered using these criteria, in this order:
In addition, scheduling can be restricted to devices specified by the admin using: