Hi folks,
The 2020.10 tag has been pushed to master on git.lavasoftware.org.
.deb packages have been built in GitLab CI and are published at
https://apt.lavasoftware.org/release
Docker images for amd64 and arm64 have been built in GitLab CI and
are available from
https://hub.lavasoftware.org/
and
https://hub.docker.com/u/lavasoftware
Changes in this release
==================
# Upgrading
No database migrations are included in this release.
# Device-types
## New device-types
New supported devices:
* imx8dx-mek
* imx8mq-zii-ultra-zest
# Secret management for deploy action URLs
We now support custom headers in the GET requests for deploy action URLs
(images, kernel, ramdisk etc) in the job definition [schema](
https://docs.lavasoftware.org/lava/pipeline-schema.html#job-submission-sche…
).
This mainly serves for passing the authentication tokens for the services
which
require one (ie. gitlab).
LAVA now also supports per user token management (found in both admin app
and
in the Profile page). Every entry will have a `token name` and the token
itself.
If the `headers` entry in the job definition contains the existing token
name
in the list of submitters list of tokens, the system will replace it with
the
token value in the header when downloading artifacts from the deploy
section.
The token values will never be visible in the job definition and also the
user
submitting the job will only ever be able to use own tokens.
Example:
```yaml
images:
kernel:
image_arg: '-kernel {kernel} -append "console=ttyAMA0,115200
root=/dev/ram0 debug verbose"'
url:
https://git.lavasoftware.org/api/v4/projects/61/jobs/112514/artifacts
headers:
"PRIVATE_TOKEN": my_private_gitlab_token
sha256sum:
c45f07a9c0ebd0c06a9dcb9676d7aada63967e0733d072f9e529b697a8a7c6ca
```
# XMLRPC and rest APIs
## Job and worker token
Super users can now get Job and Worker token from the rest api endpoints.
The field is called `token`.
```json
{
"hostname": "staging01.lavalab",
"health": "Active",
"state": "Online",
...
"token": "<worker_token>"
}
```
For XMLRPC, only the worker token is available.
# Notifications and celery
Sending notifications for large jobs can take a large amount of CPU and
time. For instances that uses a lot of notifications, admins can delegate
this work to a celery worker.
In order to use this new feature, admins should:
* pick and install a celery broker (rabbitmq, redis, ...)
```shell
sudo apt-get install redis-server python2-redis
```
* update the settings
```yaml
CELERY_TASK_ALWAYS_EAGER: false
CELERY_BROKER_URL: "redis://localhost:6379/0"
```
* restart `lava-server-gunicorn` and activate `lava-celery-worker`
```shell
sudo service lava-server-gunicorn restart
sudo systemctl enable lava-celery-worker
sudo service lava-celery-worker start
```
The use of `celery` and `lava-celey-worker` is optional. By default, LAVA
will continue to send notification like in previous releases.
## DUT environment
Environment variables can be set on the DUT by updating the configuration
file. The configuration could be stored in:
* `/etc/lava-server/dispatcher.d/{name}/env-dut.yaml`
* `/etc/lava-server/env.dut.yaml`
The filename where not consistent. Starting from this release, the
configuration files are:
* `/etc/lava-server/dispatcher.d/{name}/env-dut.yaml`
* `/etc/lava-server/env-dut.yaml`
* `/etc/lava-server/env.dut.yaml`
`/etc/lava-server/env.dut.yaml` is **deprecated** and will be dropped in a
future version.
# Crashes
Some crashes where fixed in the release:
* `docker test action` crash when using test definition dependencies
* `lava-dispatcher-host` crash in race condition
* `lava_scheduler_app` crash with some really long log lines
* `lava-server manage linaro_ldapuserlist` crash after python3-ldap upgrade
* `lava-worker` crash with version mismatch
* `lava-worker` crash when `result.yaml` is empty
Thanks
--
Rémi Duraffort
LAVA Architect
Linaro
