[Neil] Starting lava-run in a dedicated container: #114 (closed):
Admins to control external, static, udev rules to manage USB devices on the worker:
No use of udev_trigger events or adding devices within a test job, that becomes the role of the external udev rule to make sure /dev/staging-hikey-r2-01 points at /dev/bus/usb/002/075 and that this gets updated to /.../076 after reboots etc. without involving LAVA - LAVA simply adds a known symlink to the docker using volumes.
Dave already has work underway for all of this.
Dave found a problem needing the container name to update /sys/ to enable the visibility.
put a static file in /var/cache/lava-slave - named by the device hostname and containing the container name. lava-slave erases the the file when the job ends.
Test job to control the image to be used
LAVA specifies the name of the container in advance.
Documentation to recommend using official LAVA Software Community Project docker images
some teams will want to build & use images based on those
include tools which take a long time to install / build.
Is LAVA to output a warning based on a regex / checking for lavasoftware in the name? - test writer problem.
LAVA will need to clearly output the docker image being executed and retain that in the permanent test job log output or result metadata.
must handle "latest" and turn it into a reproducible ID
use docker inspect to get image ID
lava-slave does the inspection
passes an option to lava-run to log the details.
LAVA already outputs the version of lava-dispatcher (lava-run) in use (and other tools) and this will continue with docker.
Admins to control certificates, e.g. ZMQ
certificates already mean that workers need some configuration, but it is static - like the se2net configuration.
[Dean B] Capabilities may need to be added too.
LAVA runs the container with --rm (possibly with --force too).
We can delay 2019.02 until the core of this support is tested, into 2019.03 too.