Hi folks,
The 2019.06 tag has been pushed to master on git.lavasoftware.org. .deb packages have been built in GitLab CI and are available at
https://apt.lavasoftware.org/release
Docker images for amd64 and arm64 have been built in GitLab CI and are available from
and
https://hub.docker.com/u/lavasoftware
Changes in this release =======================
Device-types ============
New device-types ----------------
New supported devices:
* dragonboard-845c * meson-g12b-odroid-n2 (Amlogic) * ox820-cloudengines-pogoplug-series-3 (CloudEngines) * stm32mp157c-dk2 (STMicroelectronics) * sun50i-a64-bananapi-m64 (Allwinner) * sun7i-a20-cubieboard2 (Allwinner) * sun8i-a83t-bananapi-m3 (Allwinner) * sun8i-r40-bananapi-m2-ultra (Allwinner)
docker ------
Add an option to start docker device as privileged. Add `{% set docker_privileged = True %}` to the device dictionary.
qemu ----
Add support for `nios2` and `xtensa` architectures.
ssh ---
The ssh username can now be set in the device dictionary.
Boot methods ============
OpenOCD -------
A new boot method called `openocd` has been contributed. This method, allows to flash and boot boards using `openocd`.
An openocd job would look like:
- deploy: to: tmpfs images: binary: url: http://.../zephyr.elf openocd_script: url: http://.../cc3220_xds110.cfg - boot: method: openocd - test: monitors: - name: tests start: (tc_start()|starting .*test|BOOTING ZEPHYR OS) end: PROJECT EXECUTION SUCCESSFUL pattern: (?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)\r\n fixupdict: PASS: pass FAIL: fail
For the moment, only the `cc3220SF` board supports this method.
Test shell ==========
result strings ---------------
In LAVA versions prior to 2019.01 both lower and upper case results were accepted. This behavior was changed in 2019.01 to only accept lower case.
In order to keep compatibility among test jobs, the upper case result strings (`PASS`, `FAIL`, `SKIP` and `UNKNOWN`) are now valid again.
environment -----------
A new variable, called `environment` has been added to the device dictionaries. These can be used, for example, to describe physical hardware connections between the DUT and interfaces on the worker or other addressable hardware.
For ease of use, LAVA will directly export the content of the `device_info`, `environment`, `static_info` and `storage_info` dictionaries into the test shell environment. The dictionaries and lists will be unrolled, for example:
{% set environment = {"RELAY_ADDRESS": "10.66.16.103", "REMOTE_SERIAL_PORT": "/dev/ttyUSB2"} %} {% set static_info = [{"board_id": "S_NO81730000"}, {"board_id": "S_NO81730001"}] %} {% set storage_info = [{'SATA': '/dev/disk/by-id/ata-ST500DM002-1BD142_W3T79GCW'}] %}
will become:
export RELAY_ADDRESS='10.66.16.103' export REMOTE_SERIAL_PORT='/dev/ttyUSB2' export LAVA_STATIC_INFO_0_board_id='S_NO81730000' export LAVA_STATIC_INFO_1_board_id='S_NO81730001' export LAVA_STORAGE_INFO_0_SATA='/dev/disk/by-id/ata-ST500DM002-1BD142_W3T79GCW'
REST API ========
Filtering has been activated in the REST API for 'devices', 'device-types' and 'jobs'. See the [documentation](https://docs.lavasoftware.org/lava/data-export.html#filtering) for the details.
Table size ==========
The LAVA web interface displays a lot of tables. The size of the table is now configurable at instance level by the admin.
Update `settings.conf` and restart `lava-server-gunicorn`:
"DEFAULT_TABLE_LENGTH": 50,
By default, every table will display 25 elements.
lava-slave ==========
Socks proxy -----------
When connecting with `lava-master` and `lava-logs`, `lava-slave` can now use a socks proxy if needed.
In order to use a socks proxy, you should either: * start lava-slave with `--socks-proxy localhost:8081` * edit `/etc/lava-dispatcher/lava-slave` and add `SOCKS_PROXY="--socks-proxy localhost:8081"`
The support is now complete.
Job definition schema =====================
Job context -----------
The schema validator is now checking the content of the `context` dictionary for both single and multinode jobs.
A new set of keys has been added: `boot_character_delay`, `booti_dtb_addr`, `booti_kernel_addr`, `booti_ramdisk_addr`, `bootm_dtb_addr`, `bootm_kernel_addr`, `bootm_ramdisk_addr`, `bootz_dtb_addr`, `bootz_kernel_addr`, `bootz_ramdisk_addr`.
Only the following keys are now allowed: * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` * `booti_dtb_addr`, `booti_kernel_addr`, `booti_ramdisk_addr`, `bootm_dtb_addr`, `bootm_kernel_addr`, `bootm_ramdisk_addr`, `bootz_dtb_addr`, `bootz_kernel_addr`, `bootz_ramdisk_addr` * `boot_character_delay`, `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`, `uboot_extra_error_message`, `uboot_needs_interrupt`
Jobs using keys that are not listed in this list will be rejected.
If you think that some more keys should be whitelisted, talk to us.
XML-RPC =======
Two functions called `scheduler.workers.get_env` and `scheduler.workers.set_env` have been introduced. These functions allow users to get and set the environment for a given dispatcher.
The corresponding command line has been added to `lavacli` v0.9.7:
$ lavacli workers env get dispatcher01 $ lavacli workers env set dispatcher01 env.yaml
Steve, for the LAVA team