Upgrading
=========

Database migrations
-------------------

A new `master_version_notified` field has been added to the `Worker` model. The field will be used to know if admins where notified of the version mismatch between master and dispatchers.

Device-type templates
---------------------

The post-installation script will look at the device-types templates in `/etc/lava-server/dispatcher-config/device-types/` and remove the templates that are already present in `/usr/share/lava-server/device-types/` (and identical).

Device-types
============

New device-types
----------------

New supported devices:
* imx6q-sabreauto
* imx8dxl-evk
* imx8mp-evk
* imx8qm-mek
* imx8qxp-mek
* ls1012ardb
* ls1028ardb
* ls1046ardb
* ls1088ardb
* fsl-s32v234sbc (and s32v234-evb)
* mt8173-elm-hana

U-Boot
------

The `uboot_error_messages` variable allows device-type templates to set their own list of u-boot error messages as required if the default set is not appropriate. For example it may be required that one of the default error messages is ignored.
```jinja
{% set uboot_error_messages = [
      'Resetting CPU',
      'Must RESET board to recover',
      'TIMEOUT']
%}
```
   
The `uboot_extra_error_message` variable can still be used in conjunction with `uboot_error_messages`.

Minnowboard
-----------

Replace `boot_message` by `kernel_start_message` as the latter has been deprecated for a long time.

nfs boot commands
-----------------

Drop "intr" mount option that has been deprecated in 2.6.25. This is the default value since 2.6.25.

OpenOCD
-------

Open serial connection prior to invoking OpenOCD in OpenOCD boot method
   
The serial connection should be opened prior to invoking OpenOCD. This fixes an issue where on some devices verbose serial output is truncated when the data size exceeds buffering in the firmware.

Download
========

When downloading artifacts fail for network issues, LAVA `dispatcher` will retry up to 15 times over 10 minutes.
These retries will fix some intermittent failures.

API
===

New system endpoints
--------------------

We've added a support for getting the system version and current user

New endpoints available for REST API:

* `/api/v0.2/system/version/`
* `/api/v0.2/system/whoami/`

New test endpoints
------------------

The endpoint will allow to access the tests for a given job at:

* `/api/v0.2/jobs/<job_id>/tests/`

The results are also available at:

* `/api/v0.2/jobs/<job_id>/suites/<suite_id>/tests/`

docker
======

Site
-----

When starting `lava-server`, you can set the `Site` by setting the `LAVA_SITE` environment variable.

Superuser
---------

When starting `lava-server`, the entrypoint can create a super user for you. Just set `LAVA_ADMIN_USERNAME` and `LAVA_ADMIN_PASSWORD` environment variable.

Interactive tests and multinode
===============================

Implement multinode synchronization and `delay` primitives.
   
Introduce `delay` primitive to wait a given number of seconds (incl. fractional) and `lava-send`, `lava-wait`, `lava-wait-all`, `lava-sync` for multinode synchronization.
   
Syntax for multinode primitives follows one used in test-definitions, i.e. single-line based.

A job definition would look like:

```yaml
- test:
    role: [server]
    interactive:
    - name: boot
      prompts: ["/ #"]
      echo: discard
      script:
      - command: ifconfig
        name: result
        successes:
        - message: "inet addr:(?P<ip>\\d+\\.\\d+\\.\\d+\\.\\d+)"
      - lava-send: booted ipaddr={ip}  
- test:
    role: [client]
    interactive:
    - name: boot
      prompts: ["/ #"]
      echo: discard
      script:
      - delay: 5
      - lava-send: booted
      - lava-wait-all: booted
      - command: 'echo "Other side has IP: {ipaddr}"'
```

In this example, LAVA will capture the IP in the success message on the server and use the value in the client command.

LAVA settings
=============

In previous LAVA versions, the settings are stored in:
* `/etc/lava-server/instance.conf`: database settings
* `/etc/lava-server/settings.conf`: global settings (json)
* `/etc/lava-server/secret_key.conf`: secret key created on the fly

In order to make admin task easier, the settings are now stored in yaml files under `/etc/lava-server/settings.d/`.

The legacy configuration files will be loaded first and then the files in `/etc/lava-server/settings.d/` in alphabetical order.

Upgrade notification
====================

When `lava-master` restarts, it will check that the remote dispatchers are running the same version. If that's not the case, `lava-master` will send a mail to each worker admin.

This feature can be activated in the settings:

```yaml
MASTER_UPGRADE_NOTIFY: true
```

Test job log
============

Prior to this release, LAVA would always store test job logs on the filesystem in `/var/lib/lava-server/default/media/job-output/<year>/<month>/<day>/<id>`.

Starting from this release, admins can configure the logger backend to either the filesystem (default) or [mongodb](https://www.mongodb.com/).

In order to use Mongodb, admin should install `python3-pymongo` and update the settings:
```yaml
LAVA_LOG_BACKEND: "lava_scheduler_app.logutils.LogsMongo"
MONGO_DB_URI: "mongodb://<username>:<password>@localhost:27017/"
```

The mongodb support is currently in Beta mainly because performances can still be improved.
--