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.