LAVA基础知识整理

LAVA概述

LAVA的全称是 Linaro Automation and Validation Architecture, 是Linaro维护的一个持续集成系统,用来部署运行测试程序的物理主机或虚拟主机部署.这些测试程序可以是boot 测试, bootloader 测试或者系统级测试; 测试结果会被全程跟踪,并且测试数据能被导出用于未来分析.

According to https://validation.linaro.org/static/docs/v2/first-installation.html

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.

software Requirements

LAVA is developed using Debian packaging to ensure that daemons and system-wide configuration is correctly updated with changes in the codebase. There is no support for pypi or python virtual environments or installing directly from a git directory. 
We currently recommend installing LAVA on Debian stretch, buster or unstable. Installations using stretch (the current Debian stable release) should use updates available in backports.
LAVA software has now moved to Python3 support. This also means that Jessie is no longer supported.

 

LAVA框架

Features and Pre-requisites：

• LAVA is written in Python.
• The web interface is a Django application.
• The pipeline model uses YAML (so you’ll need the YAML Parser) and Jinja2.
• The Django backend used with LAVA is PostgreSQL and some postgres-specific support is used.
• The LAVA UI has some use of Javascript and CSS.
• LAVA also uses ZMQ and XML-RPC and the LAVA documentation is written with RST.
• In addition, test jobs and device support can involve use of U-Boot, GuestFS, ADB, QEMU, Grub, SSH and a variety of other systems and tools to access devices and debug test jobs.
• All LAVA software is maintained in git, as are many of the support scripts, test definitions and job submissions.

Device Requirements, to consider the followings：

https://validation.linaro.org/static/docs/v2/device-integration.html
Reproducibility
Reliability
Scriptability
Scalability
Power
Reset
Networking
Serial console

Note:
When there is any expectation that the lab will grow to support a lot of devices, take care at the earliest initial stages to plan for the infrastructure that can cope with the expected scale (and then add a bit again). It can be very expensive (in time and money) to replace the initial infrastructure like UPS or network switches or PDU.
ps:
UPS（Uninterruptible Power System/Uninterruptible Power Supply, 不间断电源）
PDU（Power Distribution Unit，电源分配单元）

 

https://validation.linaro.org/static/docs/v2/pipeline-admin.html#device-type-templates

Device type templates exist on the master in the /etc/lava-server/dispatcher-config/device-types/ directory.
Device Type Jinja is used to:

• avoid code duplication - e.g. if a U-Boot command stanza is common to a number of device types (it does not have to be all devices capable of supporting U-Boot), then the common code needs to move into the base template and be inserted using jinja.
• support multiple devices - e.g. if the configuration needs serial numbers (for adb) or references to unique IDs (like UUID of storage devices) or IP addresses (for primary ssh connections) then these can be set as defaults in the template but need a variable name which is then overridden by the device dictionary.
• support job-level overrides - if a variable exists in the device type template and that variable is not set in the device dictionary, it becomes available for the job submission to set that variable.

example：

# cat /etc/lava-server/dispatcher-config/device-types/xilinx-zcu102.jinja2 
{% extends 'base-uboot.jinja2' %}
{% set device_type = "xilinx-zcu102" %}
{% set bootloader_prompt = bootloader_prompt|default('ZynqMP>') %}
{% set booti_kernel_addr = '0x80000' %}
{% set booti_ramdisk_addr = '0x10000000' %}
{% set booti_dtb_addr = '0x14000000' %}
{% set base_ip_args = 'ip=dhcp' %}
{% set uboot_mkimage_arch = 'arm64' %}
{% set uboot_bootx_cmd = "booti {KERNEL_ADDR} {RAMDISK_ADDR} {DTB_ADDR}" %}
{% set uboot_load_fdt = "          - setenv loadfdt 'tftpb {DTB_ADDR} {DTB}'" %}
{% set uboot_tftp_commands =
"          - setenv loadkernel 'tftpb {KERNEL_ADDR} {KERNEL}'
          - setenv loadinitrd 'tftpb {RAMDISK_ADDR} {RAMDISK}; setenv initrd_size ${filesize}'
" + uboot_load_fdt -%}

You can (temporarily) copy your template into lava_scheduler_app/tests/device-types and run the unit tests to verify that the template can be parsed and rendered as valid YAML:

$ /usr/lib/python3/dist-packages/lava_server/manage.py test lava_scheduler_app.tests.test_device.DeviceTypeTest

ps:
Jinja template documentation: http://jinja.pocoo.org/docs/dev/templates/
Online YAML Parser: http://yaml-online-parser.appspot.com/
Detailed device dictionary information in LAVA Scheduler: https://validation.linaro.org/static/docs/v2/lava-scheduler-device-dictionary.html#device-dictionary-exported-parameters

 

Job Methods

• Deployment methods
  All test jobs involve a deployment step of some kind, even if that is just to prepare the overlay used to copy the test scripts onto the device or to setup the process of parsing the results when the test job starts.

• Boot methods
  Hardware devices need to be instructed how to boot, emulated devices need to boot the emulator. For other devices, a boot can be simply establishing a connection to the device.

• Test methods
  The principal test method in LAVA is the Lava Test Shell which requires a POSIX type environment to be running on the booted device. Other test methods available include executing tests using ADB.

原理:
Lava Dispatcher Design  https://validation.linaro.org/static/docs/v2/dispatcher-design.html#using-strategy-classes

job yaml 语法:
Deploy Action Reference  https://validation.linaro.org/static/docs/v2/actions-deploy.html#to-fastboot
Boot Action Reference  https://validation.linaro.org/static/docs/v2/actions-boot.html#boot-action
Test Action Reference  https://validation.linaro.org/static/docs/v2/actions-test.html#test-action

示例:
Writing YAML job submission files  https://validation.linaro.org/static/docs/v2/dispatcher-format.html

 

Basic structure for device_type configuration

To take advantage of the new dispatcher design and to make the LAVA device configuration more consistent, a new format is being created for the device_type and device configuration files, again using YAML.

The device type outlines which strategies devices of this type are able to support. The parameters and commands contained in the device_type configuration will apply to all devices of this type.

The main block is a dictionary of actions. Each item is the name of the strategy containing a list of arguments. All strategies require a method of how that strategy can be implemented. The methods supported by this device type appear as a list.

actions:
 deploy:
   # list of deployment methods which this device supports
   methods:
     - image
   # no need for root-part, the MountAction will need to sort that out.
 
 boot:
   prompts:
     - 'linaro-test'
     - 'root@debian:~#'
   # list of boot methods which this device supports.
   methods:
     - qemu
   # Action specific stanza
   command:
     # allows for the one type to support different binaries
     amd64:
       qemu_binary: qemu-system-x86_64
   # only overrides can be overridden in the Job
   overrides:
     - boot_cmds
     - qemu_options
   parameters:
     boot_cmds:
       - root: /dev/sda1
       - console: ttyS0,115200
     qemu_options:
       - -nographic
     machine:
        accel=kvm:tcg
     net:
       - nic,model=virtio
       - user

Device type information in LAVA Scheduler:

https://validation.linaro.org/static/docs/v2/lava-scheduler-device-type-help.html#device-type-metadata

 

LAVA schema:

 https://validation.linaro.org/static/docs/v2/pipeline-schema.html