2017.4 will deliver support for migrating V2 health checks out of the
database and into /etc/lava-server/dispatcher-config/health-checks/ on
the master. This has several benefits for admins.
* Health checks from 2017.4 onwards will be based on the device
configuration, not the device type. This applies to V1 devices and V2
devices.
* Multiple instances can all have the same V2 health checks controlled
in VCS using configuration management tools.
* V2 devices of the same device-type can have different V2 health
checks according to the Jinja2 template specified in the extends field
of the device dictionary. Submissions to such devices would need to be
managed through device tags.
* Devices which are V1 only (is_pipeline is False in the django admin
interface) will continue to use V1 health checks from the database,
based on the device-type.
* Devices which support V2 (whether these devices are exclusive to V2
or not) will only use V2 health checks from the filesystem, based on
the device dictionary of each device.
This does mean that devices which are currently both V1 and V2 will
need to have a V2 health check from 2017.4 onwards or the device will
no longer run a health check at all. Admins may choose to submit and
monitor regular V1 testjobs until all test jobs for those devices are
V2 but those test jobs will not be able to take the device offline
automatically.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
There is a bug in python-lockfile available from jessie-backports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858835
This affects fresh installs of LAVA when LAVA is installed directly
from jessie-backports without first being installed in jessie.
The underlying problem is with apt which pulls in the updated version
of packages which have a backport available even if the requested
package does not explicitly ask for the backport of that package.
The problem shows up with lava-coordinator first - the package fails
to install cleanly because the daemon cannot be started correctly.
To fix this problem, simply instruct apt to install python-lockfile
from jessie, not from jessie-backports:
apt install python-lockfile=1:0.8-2
lava-coordinator will then install correctly.
This change will persist over later upgrades as apt does not consider
jessie-backports as upgrades of jessie - except in the case where the
package is not yet installed.
Other daemons also now need to be restarted:
$ sudo service lava-server restart
$ sudo service lava-master restart
$ sudo service lava-slave restart
Future builds for the staging-repo and production-repo will force only
version 1:0.8-2 of python-lockfile as these builds are done on and for
jessie.
Systems already running Stretch or unstable do not seem to be affected
and can safely use python-lockfile at version 1:0.12.2-2 - this is a
particular problem inside jessie-backports. However, this does mean
that until this bug is fixed, users running Stretch or unstable should
build their own developer packages instead of using the LAVA
repositories on images.validation.linaro.org. We currently do not have
capacity to build separate packages for jessie and stretch.
(LAVA does not recommend using Stretch or unstable for production
systems until Stretch has been released and stretch-backports becomes
available.)
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
