Upgrading
=========
Database migrations
-------------------
No database migrations are included in this release.
Device-types
============
New device-types
----------------
New supported devices:
- ls1021a-tw
QEMU
----
Add support for riscV. The architecture would be `riscv64`.
U-Boot
======
When booting with u-boot, lava can now load tee over tftp. User should provide a resource called `tee` in the deploy action.
```yaml
- deploy:
to: tftp
tee:
url: file:/local/lava-ref-binaries/fsl-imx6q-sabresd-linux/uTee-6qsdb
```
uuu
===
When booting with `uuu`, user can specify a docker container that will use to run the `uuu` binary. The job definition would look like:
```yaml
actions:
- boot:
method: uuu
commands:
- uuu : -b sd {boot}
docker:
image: atline/uuu:1.3.191
```
Admins can specify a default docker image in the device dictionary:
```jinja
{% set uuu_docker_image = "atline/uuu:1.3.191" %}
```
If the DUT is not directly connected to the dispatcher, you can enable the `remote uuu` support:
```jinja
{% set uuu_remote_options = "--tlsverify --tlscacert=/remote_ca.pem --tlscert=/remote_cert.pem --tlskey=/remote_key.pem -H
10.192.244.5:2376" %}
```
Docker test action
==================
Power commands
--------------
When using a docker test action, the power commands are now available as environment variables:
* `LAVA_HARD_RESET_COMMAND`
* `LAVA_POWER_ON_COMMAND`
* `LAVA_POWER_OFF_COMMAND`
Note that each of these operations can actually require more than one command, in which case the corresponding environment variable will have the multiple commands with `&&` between them.
Because of this, the safest way to run the commands is passing the entire contents of the variable as a single argument to `sh -c`, like this:
```bash
sh -c "${LAVA_HARD_RESET_COMMAND}"
```
Android serial
--------------
Add `LAVA_BOARD_ID` as an alias for `ANDROID_SERIAL`.
Extra bind mounts
-----------------
Admins can specify extra files and directories that lava will bind mount when executing the docker test action.
This is set per dispatcher in the dispatcher configuration file:
```yaml
# Directories to be bind mounted in test actions that run with docker.
# Must be an array with exactly two/three items:
# 1st item: the source directory in the host (mandatory)
# 2nd item: the destination directory in the container (mandatory)
# 3rd item: bind mount mode (optional)
# default is read-only if this item omitted
# set as "rw" could make the directory in container writable
test_docker_bind_mounts:
- [<bind-mount1-host-path>, <bind-mount1-container-path>]
- [<bind-mount2-host-path>, <bind-mount2-container-path>, "rw"]
```
Docker in actions
=================
Local images
------------
When using a docker image for actions that support it (`docker`, `fastboot`, `fvp`, `qemu` and `uuu` for the moment), LAVA will run `docker pull` then `docker run`.
When using local image, the call to `docker pull` will fail. This version add the possibility to use local images:
```yaml
- boot:
docker:
name: "my-docker-image"
local: true
```
Init
----
Always run with an init system. The docker command is now `docker run --init ...`.
Gunicorn worker class
=====================
By default gunicorn is using the "sync" worker which is not suitable for long
requests like downloading large log files.
When using an async worker (like eventlet), the worker can process multiple
long running requests at the same time while answering to master pings. In
this case, requests are not aborted after timeout, allowing to
download large log files.
Release %2020.07 introduced an option to change the gunicorn worker class while keeping `sync` as the default.
After many tests on Linaro LAVA instances, this release change the default worker class from `sync` to `eventlet`. As a result `lava-server` now depends on `python3-eventlet`.
Test job log
============
When migrating to another log storage handler, like `mongodb` or `elasticsearch`, admins can now migrate every job logs using `copy-logs` command:
```bash
sudo lava-server manage copy-logs LogsMongo
```
This command will go through every test job and migrate the logs from the file system to the right log handler.