LAVA Overview

[ LAVA V1 ] [ LAVA V2 ]

Return to LAVA site: [ Home ] [ Dashboard ] [ Results ] [ Scheduler ] [ API ]

What is LAVA?

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, the overall idea and evolving architecture that allows us to make testing, quality control and automation. LAVA-the-stack aims to make systematic, automatic and manual quality control more approachable for projects of all sizes.

LAVA is for validation - telling whether the code the other Linaro engineers are producing “works” in whatever sense that means. It could be a simple compile or boot test for the kernel, testing whether the code produced by gcc is smaller or faster, whether a kernel scheduler change reduces power consumption for a certain workload, or many other things.

Beyond simple validation though, what LAVA really about is automated validation. LAVA builds and tests the kernel on all supported boards every day. LAVA builds and tests proposed android changes in gerrit before they are landed, and the same for the gcc work. There is a validation lab in Cambridge - the boards from the Linaro members we want to test on, but also Cyclades serial console servers, routers, and a few servers.

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.

LAVA Migration

LAVA is currently in the middle of a migration from the V1 model to a new design, called the Pipeline Model, to create V2. These help pages are divided into V1 and V2. Some LAVA instances will only support V2, some will support both and some may only support V1. However, V1 support will be removed at some point in 2017, so instances which do not migrate to V2 will not be able to receive updates.

Note

Please subscribe to the Mailing lists for information and support.

LAVA V1

V1 refers to the components of LAVA which are related to:

  • JSON job submissions
  • Bundles, BundleStreams and submit_results
  • Image Reports and Image Reports 2.0

All code supporting V1 is deprecated as of the 2016.2 release and is scheduled to be removed from the codebase during 2017.

Warning

When the code objects are removed, the corresponding database records, tables, indexes and relationships will also be deleted. Instances which want to continue using V1 from 2017 onwards must not install updates or all V1 data will be lost.

See also

LAVA V1

LAVA V2

V2 refers to the pipeline model - a new design for how the test job is constructed which also delivers a much simpler way of deploying distributed instances and gives test writers a lot more room to write new test jobs using new protocols and test methods.

  • YAML job submissions, supporting comments
  • Results, Queries and Charts
  • Live result reporting (no final submission stage)
  • Simplified setup for distributed instances

The code supporting V2 is being extended to support a wider range of devices and deployment methods, with the migration to V2 expected to last until the end of 2016.

See also

LAVA V2

Getting support

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:

Guidelines

  • Avoid putting LAVA job output directly into your email to a list or IRC channel. Mailing list posts can include a few lines but not IRC.
  • If you are using the LAVA V1, rather than LAVA V2, you need to always re-run your test with logging_level: DEBUG if you have not done so already.
  • Always use a pastebin for log output and include a link to the paste in your post. Pastebins can be provided by your distribution or other sources - the internal Linaro pastebin requires the user to register. Example pastebins which are open to anyone include pastebin.com and paste.debian.net. Pastes will typically expire automatically, depending on the option selected by the user making the paste.
  • Paste from the complete log, not the summary, so that you get the complete lines.
  • Include in this paste or another paste, the job definition you used.
  • Provide details of which server you are using (with a URL if it is publicly visible or a version string from the documentation pages if not) and details of the actual device(s) in use.

Mailing lists

The primary method for support for LAVA is based on mailing lists.

A few guidelines apply to all such lists:

  • Reply to the list, adding the submitter in CC where appropriate.
  • If your job uses URLs which are not visible to the rest of the list, include a rough outline of how those were built and what versions of tools were used.
  • Avoid top posting.
  • Always provide as much context as you can when phrasing your question to the list.

lava-users

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

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.

lava-announce

Subscribing to the lava-announce list is recommended for everyone using LAVA, whether a test writer 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 uses to CC you on replies.

IRC

IRC is a common support method for developers. Our team is spread geographically around the world, with some members in Europe, America, Asia. We are usually talking on our IRC channel #linaro-lava on irc.freenode.net.

Guidelines apply to IRC as well:

  • Use a proxy or other service which keeps you connected to IRC. Developers are based in multiple timezones and not everyone can answer all queries. Therefore, you may have to wait several hours until the relevant person or people are awake. Check back for replies on the channel intermittently. If you disconnect, you will not see any replies sent whilst you were disconnected from the channel.
  • Ask your question, do not wait to see people joining or talking.
  • As with mailing lists, it is even more important with IRC that you always use a pastebin. See Guidelines.
  • Do not assume that the person someone else spoke to last is also able to answer your question.
  • Do not assume that the person you spoke to last is also able to answer your other question(s).
  • Reply directly to a person by putting their IRC nickname at the start of your message to the channel. In a busy channel, it can be hard to spot replies not made to you.
  • Developers are busy - IRC is part of our development process, so please be considerate of the amount of time involved, there is code to write and there are bug fixes to make for other users as well.
  • Avoid personal messages unless there is a clear privacy issue involved or you know the person well.
  • You may well find that one of the Mailing lists actually provides a faster answer to your question, especially if you are new to LAVA.

Using tables in LAVA

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.

Table search support

Note

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.

Custom table queries

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.

Note

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.)

Exclusive table searches

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:

?device=mx5&length=25&description=ARMMP&status=Incom

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.

Note

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.

Other filters

Individual tables may also provide filters via javascript or other support.

Resetting a table

The breadcrumb link should take you back to the default table. Alternatively, clear the querystring in the browser address bar manually.

Unavailable entries

Certain tables may contain data relating to a hidden device type which would show as Unavailable if the user viewing the table does not own a device of this type. It is not possible to search these tables for details of the hidden type and the Unavailable label itself does not match as a search term.