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 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:

  • testing whether changes in the Linux kernel compile and boot
  • testing whether the code produced by gcc is smaller or faster
  • testing whether a kernel scheduler change reduces power consumption for a certain workload
  • etc.

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

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

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 the submit_results action
  • 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 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.

See also

LAVA V1

LAVA V2

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.

  • 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. The migration to V2 is 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

  • If you are having problems, it may be helpful to check the mailing list archives first - somebody else may have already seen and solved a similar problem.
  • 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 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. Pastebin services are provided online by multiple people. Some are open to anyone, such as pastebin.com and paste.debian.net. Others (like the internal Linaro pastebin) are restricted and will require users to register. Pastes will typically expire automatically, depending on the options selected by the user creating the paste.
  • Paste content from the complete log, not the summary, so that you get the complete lines.
  • Include the job definition you used, either in this paste or another paste.
  • If you are administering your own instance, also include the device type template and an export of the device dictionary.
  • 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 our 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 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

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:

  • 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. Don’t ask if you may ask a question!
  • 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.