Changes to LAVA UI configuration
================================
https://master.lavasoftware.org/static/docs/v2/advanced-installation.html#c…
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_FORW…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
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
