After completing the New Staff Tasks you can start getting your feet wet with LAVA.

The Team

The best way to get to know people is on IRC. Here's the channel information you'll need. Specifically #linaro-lava will be most useful to you. If you already have an established IRC presence in the free software community, you are encouraged to use the same nick. Some of the team have established nicks, these include:





Neil Williams

LAVA Software Tech Lead


Senthil S Kumaran

LAVA engineer


Milo Casagrande

LAVA engineer


Fathi Boudra

Build and Baselines Tech Lead

We also have some mailing lists of interest:

Please respond to any questions and reports to which you can make a useful contribution. It is particularly useful to have team members from a variety of timezones replying on the mailing lists.

Another handy thing is to browse our Meet The Team page. This will let you know who's who and also see what we all look like.

Team meetings are done using Google Hangouts. You should use a headset to prevent echoes being audible to other team members when you are on the call. You will receive invitations to meetings via email, including a 1:1 sync with the Tech Lead, usually on a Thursday.

System Access

Access to systems in Linaro (and the LAVA team) are managed via your Linaro LDAP details and the SSH keys configured on it. Systems you'll want access to:

This is not required, but its a handy place to store things you may want to share. It also has a ~/public_html directory where you can share web-links if needed.

The LAVA servers are on a private network, but we have an SSH gateway that you can bounce in through. We manage access to these servers by virtue of being a member of the linaro group on LDAP. Here's a sample .ssh/config file that should get you going:

Host *.lava
ServerAliveInterval 60
ProxyCommand ssh gateway-lava nc -q0 `basename %h .lava` %p

For now, just ensure you have access to staging-master.lava, don't go and do anything crazy ... for now :)

Linaro Process

Learning LAVA

We can use the website to begin to understand the relationship of components in LAVA.

Pay particular attention to the division between LAVA V1 and LAVA V2 documentation. Ensure you have understood the LAVA V2 design as this is the focus of all ongoing development. LAVA V1 is deprecated but still in use and will continue to be supported during 2016. It is scheduled to be removed from the codebase in 2017.

The next portion of the validation website to learn about is the Scheduler. The scheduler is responsible for:

  • knowing what devices are in the lab
  • knowing the state the devices are in ie (idle, busy, offline, etc)
  • accepting job requests, and finding the proper device to execute it on.



The component that actually talks to the target device to be tested with. It knows how to boot, flash, and execute test jobs on the target.


A command line interface for creating, submitting and managing jobs in LAVA using the python-keyring support. You can also write your own scripts. There is an example python script on the API page of each instance.

LAVA Developer Checklist

Getting Started

When bringing up a new LAVA engineer, it is important that the engineer experiences LAVA through a few perspectives before attempting to fix bugs. The following checklist will help a new developer create an environment to use, test and reproduce issues during development.

  1. Familiarize yourself with the LAVA web interface

    1. Familiarize yourself with the LAVA Documentation

  2. Install your own LAVA instance using Debian Jessie
    1. LAVA is currently only supported on Debian. it is a normal package available from the Debian mirrors. The installation process is covered in the documentation.
      1. Updates are available for Jessie using jessie-backports.
      2. You can install LAVA in a Debian Jessie virtual machine but be aware that this will cause issues with some devices which require USB support.
    2. pypi or python virtualenv are not supported and must not be used with LAVA. Symlink farms can be used but are down to individual developers to manage, setup and debug.

    3. Pay particular attention to Javascript handling

  3. Create a QEMU device type and a device using that type.
    1. Don't mess with the intricacies of real hw, yet :)

  4. Submit 15 jobs for this device type
    1. 5 though the GUI
    2. 5 through the command line as JSON
    3. 5 through the command line as pipeline V2.
  5. Create a Filter
  6. Create a Query
  7. Create an Image Report 2.0
  8. Create a Chart
  9. Add a new test
    1. Parse general results
    2. Parse a measurement
    3. If you chose something useful, push for review into

  10. Build and install developer build packages using the tools provided with the lava-dev package.
  11. Throughout this process, it's likely you have encountered some areas we can improve our documentation
    1. Push at least 1 documentation improvement for review.
      1. All changes to lava software must all use gerrit.

      2. Talk to other team members about elements of the current documentation which are unclear or confusing to newcomers. In particular, talk to Steve McIntyre and provide feedback on how the docs can be improved.

Next steps

  1. LAVA is a distributed test environment. To adequately test your fixes you'll likely also need to create a local virtual distributed LAVA lab
    1. KVMs nest nicely if you don't get too crazy with the JOBs
      1. Create a Master / Slave (remote worker) LAVA installation (It's in the documentation)
      2. Create a LAVA V2 installation and a pipeline worker.
  2. Managing the distribution of your devices and remote workers can be hard when done manually. You should look into using SALT (like we do in the LAVA LAB) to manage your remote workers and the device distribution.

Now you are ready to get into the code


Git hygiene

  1. Avoid working on master 1.Keep one change in one local branch in most cases.
    1. $ git checkout -b branchname
    1.Pull on master and rebase the branches regularly.
  2. Commit on the local branch and ensure the branch is clean before putting for review:
    1. $ git review
  3. Respond to comments in the gerrit interface, make changes on the local branch and amend the commmit, optionally updating the commit message:
    1. $ git commit --amend
    2. $ git commit --amend --no-edit
  4. Base another local branch on an existing branch only if you are making changes which extend a change already in review. To update these reviews, use:
    1. $ git push gerrit HEAD:refs/for/master

  5. Once the review is merged, rebase and delete the local branch:
    1. $ git checkout master
    2. $ git pull
    3. $ git checkout branchname
    4. $ git rebase master
    5. $ git branch -d branchname
  6. Build local packages directly from your local git branch to test on http://localhost/

LAVA/NewStaffTasks (last modified 2016-03-29 12:35:23)