Changes to LAVA UI configuration ================================ https://master.lavasoftware.org/static/docs/v2/advanced-installation.html#co...
Initial settings for a LAVA instance change over time as the requirements change and dependencies improve internal security implementations. Most instances will need some adjustment to the apache configuration for the main LAVA UI in /etc/apache2/sites-available/lava-server.conf and the LAVA packages do not attempt to update this file automatically once admins have made changes. Admins should therefore subscribe to the lava-announce mailing list and make changes using separate configuration management.
apache2 =======
Browser caching can be improved by enabling mod_header in Apache to allow LAVA to send appropriate cache control headers as well as mod proxy and mod proxy_http:
$ sudo a2enmod header $ sudo a2enmod expires $ sudo service apache2 restart
LAVA server settings changes ============================ Django requires the allowed hosts to be explicitly set in the LAVA settings, as a list of hostnames or IP addresses which LAVA is allowed/expected to use. If this is wrongly configured, the UI will raise a HTTP 500 error and you will get information in the output of:
lava-server manage check --deploy
or in
/var/log/lava-server/django.log
For example, /etc/lava-server/settings.conf for https://lava.codehelp.co.uk/ contains:
"ALLOWED_HOSTS": ["lava.codehelp.co.uk"],
See also https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts
It is also important to enable ProxyPreserveHost in /etc/apache2/sites-available/lava-server.conf
ProxyPreserveHost On
In some situations, you may also need to set USE_X_FORWARDED_HOST to False in /etc/lava-server/settings.conf
See also https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-USE_X_FORWA...
https://git.lavasoftware.org/lava/lava/merge_requests/400
python3-junit.xml =================
python3-junit.xml >= 1.8 is required for REST API calls when running A suitable package has now been backported to provide this functionality for Stretch.
https://packages.debian.org/stretch-backports/python3-junit.xml
Note: there is a very similarly named package which will **not** work (python3-junitxml). Look for the full stop in the package name of the correct package: python3-junit.xml
When installing, remember to allow stretch-backports:
$ sudo apt -t stretch-backports install python3-junit.xml
https://git.lavasoftware.org/lava/lava/merge_requests/357
Bump version of django-tables2 ==============================
With 2019.01 and later, django-tables2 version 1.14 does not pick up the customisation of the tables, so orderable icons and search forms and pagination are missing.
It was not practical to backport django-tables2 to stretch-backports due to complexities in the build dependencies of the package. So this update has been made available via apt.lavasoftware.org
Stretch users will find a new version of python3-django-tables2 will be installed alongside 2019.02.
https://git.lavasoftware.org/lava/lava/merge_requests/390
Prevent action.timeout exceeding job.timeout ============================================
This change affects the test jobs you submit to LAVA. The test job will warn if any one action timeout exceeds the overall job timeout. LAVA is adopting a stricter submission schema and this is the first common issue.
If you have a repository containing a number of test jobs, you can check all of the jobs in one go by passing the path to a script in the lava-common package.
$ sudo apt install lava-common $ /usr/share/lava-common/lava-schema.py jobs ./*.yaml
You may want to edit the timeouts when resubmitting older test jobs.
When running /usr/share/lava-common/lava-schema.py, there may be a range of other errors reported too. In future releases, LAVA will no longer silently ignore unknown or obsolete YAML blocks. If there is an error in the submission, the expanded schema will report it.
It is worthwhile running /usr/share/lava-common/lava-schema.py against the output of all your test job submission templates. If you use templating and CI, then you could add the check to the CI of each change to the templating. Just ensure that the lava-common package is upgraded to the same version as the instance to which the test jobs would be submitted.
In the next release, this expanded schema check will be included into lavacli, lava-server manage and as an XMLRPC call which can be used before the submission. For now, only the action.timeout exceeding job.timeout warning is being enabled in 2019.02.
https://git.lavasoftware.org/lava/lava/merge_requests/413