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 - 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.)
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.
LAVA is currently in the middle of a lengthy migration from its original design (known as the V1 model) to a new design, called the Pipeline model or the V2 model. During this migration, LAVA installations will be able to support test devices and test jobs targeting both models. These help pages are divided into V1 and V2 accordingly.
While this migration is taking place, it is expected that some LAVA instances will only support V2, some will support both versions and some may only support V1. However, V1 support is deprecated and will be removed at some point in 2017. Instances which do not migrate to V2 will not be able to receive updates beyond that point so users are strongly encouraged to move to V2 as soon as possible.
Please subscribe to the Mailing lists for information and support.
V1 refers to the components of LAVA which are related to:
All code supporting V1 is deprecated as of the 2016.2 release and is scheduled to be removed from the codebase during 2017.
When the code objects implementing V1 are removed, the corresponding database records, tables, indexes and relationships will be deleted during later upgrades. Instances which want to continue using V1 from 2017 onwards must not install updates or all V1 data will be lost.
V2 refers to the pipeline model - a new design for how the test job is constructed. It gives test writers much more freedom to write new test jobs using new protocols and test methods, and it also delivers a much simpler way of deploying distributed instances.
The code supporting V2 is being extended to support a wider range of devices and deployment methods. The migration to V2 is expected to last until the end of 2016.
LAVA is free software and is provided “as is” without warranty of any kind. Support is offered using the methods below and we will try to help resolve queries.
Whenever you look for support for LAVA, there are some guidelines to follow:
The primary method for support for LAVA is our mailing lists.
A few guidelines apply to all such lists:
The lava-users mailing list concentrates on support for current LAVA tests, involving test writers, individual admins and LAVA developers. Users are encouraged to contribute to answer queries from other users.
lava-devel is an alias to linaro-validation and is aimed at supporting test writers and admins who are adapting to the LAVA V2 support and discussions relating to announcements from the LAVA developers. Replies to the lava-announce list are directed here.
Subscribing to the lava-announce list is recommended for everyone using LAVA, whether writing tests or viewing reports or administering a LAVA instance.
As the work on LAVA V2 continues, it will become increasingly important that all users of LAVA are aware of the upcoming changes, new methods available in the refactoring and the removal of old methods.
Replies to this list are sent to the lava-devel list - if you are not subscribed to lava-devel, please ask other users to CC you on replies.
IRC is a common support method for developers. Our team is spread geographically around the world, with some members in Europe, America and Asia. We are usually talking on our IRC channel #linaro-lava on irc.freenode.net.
Guidelines apply to IRC as well:
LAVA presents much of the data about jobs, devices, results and tasks inside tables. The length of a table can be controlled, the table can be sorted by selected columns and the data itself can be searched. All options can be controlled from the query string in the browser address bar. This allows particular views of a table to be shared as links. See Custom table queries.
For pages which only contain a single table, the number of rows displayed in each page of data is controlled via the length parameter. For convenience, there is a drop down box on the left of each table where the table length can be selected.
Tables are only the base representation of the data available in LAVA and whenever the table search support seems incomplete, the solution is to create a Query which can also be represented as a simple URL.
Unless specified explicitly, all table searches are case-sensitive.
The search box above each table allows arbitrary text strings to be used as filters on the data within the table. Each table has support for matching simple text strings against certain columns within the table and these searches are additive - the data in the row will be included in the results if the text matches any of the search fields.
The fields which support text search are listed above each table.
Some tables also support customised queries on specific fields, typically these will be time based fields like submit_time, end_time and duration. These queries allow a specific function to be called within the filter to match only results where the timestamp occurred within the specified number of minutes, hours or days, relative to the current time on the server.
The queries supported by a table are listed above the table, along with details of whether that query is based on minutes, hours or days.
Time based queries will always take the current time on the server into account, so links containing such queries may not give the same results when viewed at a later time.
Time based queries can take calculations in the query string as well, e.g. end_time is based on hours, so ?end_time=4*24 matches end_time within the last 4 days (the search summary will still show the 4*24.)
Fields used in simple text searches can also be used as exclusive searches by adding the exclusive search field to the querystring. The data in the row will be included in the results only if the text matches all of the search fields:
This querystring would only show rows where the device hostname contains mx5 and the description contains ARMMP and the status of the job contains Incom, therefore showing up to 25 results for jobs on such devices with that description which finished with a status of Incomplete.
Exclusive searches are not supported via the search box in the table header. Add to the querystring directly. Exclusive text search cannot be combined with simple text search. Replace the search variable in the querystring with the closest discrete query term, e.g. description.
The fields which support exclusive search are listed above each table.
The breadcrumb link should take you back to the default table. Alternatively, clear the querystring in the browser address bar manually.