First steps installing LAVA¶

Elements of the Master¶

• Web interface - This is built using the Apache web server, the uWSGI application server and the Django web framework. It also provides XML-RPC access and the REST API.
• Database - This uses PostgreSQL locally on the master, with no external access.
• Scheduler - This is the piece that causes jobs to be run - periodically this will scan the database to check for queued test jobs and available test devices, starting jobs when the needed resources become available.
• lava-server-gunicorn daemon - This communicates with the worker(s) using HTTP

Elements of the Worker¶

• lava-worker daemon - This receives control messages from the server.
• Dispatcher - This manages all the operations on the device under test, according to the job submission and device parameters sent by the master.
• Device Under Test (DUT)

Software Requirements¶

We currently recommend installing LAVA on Debian buster or unstable.

LAVA software has now moved to Python3 support. This also means that Jessie is no longer supported.

Contributions to support other distributions are welcome.

If you’d like to help us provide support for other distributions, feel free to contact us using the lava-devel mailing list.

Hardware Requirements¶

A small LAVA instance can be deployed on fairly modest hardware. We recommend at least 1GB of RAM to cover the runtime needs of the database server, the application server and the web server. For storage, reserve about 20GB for application data, especially if you wish to mirror the current public Linaro LAVA instance. LAVA uses append-only models, so storage requirements will grow over time.

If you are deploying many devices and expect to be running large numbers of jobs, you will obviously need more RAM and disk space.

Device requirements¶

Devices you wish to deploy in LAVA need to be:

• Physically connected to the server via usb, usb-serial, or serial; or
• connected over the network via a serial console server; or
• a fastboot capable device accessible from the server; or
• a virtual machine or simulator that emulates a serial connection

MultiNode hardware requirements¶

If the instance is going to be sent any job submissions from third parties or if your own job submissions are going to use MultiNode, there are additional considerations for hardware requirements.

MultiNode is explicitly designed to synchronize test operations across multiple test devices and running MultiNode jobs on a particular instance will have implications for the workload of that instance. This can become a particular problem if the instance is running on virtualized hardware with shared I/O, a limited amount of RAM or a limited number of available cores.

Also, consider the number of test devices connected to any one dispatcher. MultiNode jobs will commonly compress and decompress several large test image files in parallel. Even with a powerful multi-core machine, this can cause high load. It is worth considering matching the number of devices to the number of cores for parallel decompression, and matching the amount of available RAM to the number and size of test images which are likely to be in use.

Single Master Instance installation¶

A single instance runs the web interface, the database, the scheduler and the dispatcher on a single machine. If this machine is also running tests, the device (or devices) under test (DUT) will also need to be connected to this machine, possibly over the network, using USB or using serial cables.

To install a single master instance and create a superuser, refer to Installing on a Debian system installation.

LAVA V1 used to support a distributed_instance installation method. This has been removed in V2; instead there is a much improved architecture for remote workers using HTTP.

Detailed instructions for setting up workers follows - first, think about the kind of configuration needed for your instance.

Master with one or more workers¶

You can choose whether the master has devices configured locally or only uses devices via one or more remote workers. If you are installing and learning how to use LAVA for the first time, it is recommended to keep things simple and stick to a Single Master Instance installation to start with.

LAVA Coordinator setup¶

If you are expecting to support MultiNode jobs in your LAVA setup, there is a third component needed. The LAVA Coordinator manages the extra message passing needed between the various nodes in a MultiNode group of devices. Nodes connect to the LAVA Coordinator daemon via TCP (default port: 3079). A single coordinator can manage groups from multiple instances if desired. If the network configuration uses a firewall, ensure that this port is open for connections from MultiNode dispatchers.

If multiple coordinators are necessary on a single machine (e.g. to test different versions of the coordinator during development), each coordinator needs to be configured for a different port.

If the dispatcher is installed on the same machine as the coordinator, the dispatcher can use the packaged configuration file with the default hostname of localhost.

Each dispatcher then needs a copy of the LAVA Coordinator configuration file (JSON syntax), modified to point back to the hostname of the coordinator:

Example JSON, modified for a coordinator on a machine with a fully qualified domain name:

{
  "port": 3079,
  "blocksize": 4096,
  "poll_delay": 3,
  "coordinator_hostname": "control.lab.org"
}

An IP address can be specified instead, if appropriate.

Each dispatcher needs to use the same port number and blocksize as is configured for the Coordinator on the specified machine. The poll_delay is the number of seconds each node will wait before polling the coordinator again.

Setting Up Serial Connections to LAVA Devices¶

LAVA controls the DUT using a serial connection, except for emulated devices like QEMU.

LAVA can support multiple serial connections per DUT. The recommended method for creating a serial connection is to use Ser2net daemon to provide a connection using the telnet client. This allows simple and clean disconnection and allows LAVA to use the connection over the network. Other tools (conmux, minicom) have been tried but showed reliability problems when used at scale. LAVA is not able to directly access a device node.

ser2net is the recommendation based on several million test jobs.

#port:connectiontype:idle_timeout:serial_device:baudrate databit parity stopbit
7001:telnet:0:/dev/serial/by-id/serial_path:115200 8DATABITS NONE 1STOPBIT LOCAL