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
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-schem... ).
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