Starting lava-run in a dedicated container ===============================
https://git.lavasoftware.org/lava/lava/issues/114
Work has already been done for the device support in this area. The intention is that the admins can create static udev rules which add the device to the correct container. To achieve this, the name of the container needs to be made available to the udev rule. The plan will be for lava-slave to create a file in /var/cache/lava-slave/. The file will be named according to the device hostname and will contain the container name plus some other useful data, e.g. the job ID. the udev rule can then parse this file to know which container to use. The udev rule would be triggered on each ADD. If lava-slave is run in a docker, /var/cache/lava-slave/ would need to be made available to that docker as a volume. (LAVA specifies the name of the container in advance.)
Test job to control the image to be used -----------------------------------------------------
The LAVA documentation will need to recommend using official LAVA Software Community Project docker images, some teams will want to build & use images based on those to help include tools which take a long time to install / build. LAVA will not be able to check the provenance of the images being used, this is a 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. lava-slave will need to handle "latest" URLs and turn it into a reproducible ID using docker inspect to get the image ID. This is to be done by passing an argument to a new lava-run option.
LAVA already outputs the version of lava-dispatcher (lava-run) in use (and other tools) and this will continue with docker.
Admins will continue to control certificates, e.g. ZMQ
Capabilities may need to be added too.
LAVA runs the container with --rm (possibly with --force too).
Releases and milestones ===================
We have created a 2019.03 milestone which is expected to contain the work on lava-run in a separate container above. We have moved a number of issues and merge requests from 2019.02 into 2019.03 (or sometimes into .05) to get to a feasible number of changes to release 2019.02.
Adding env variables to the test shell =============================
In combination with https://git.lavasoftware.org/lava/lava/issues/228 we will be looking at making device dictionary elements and some environment variables available inside the Lava-Test Test Definition 1.0 overlays using a test shell helper. Test writers are advised not to rely on device-specific information unless essential.
On Wed, 13 Feb 2019 at 15:24, Neil Williams neil.williams@linaro.org wrote:
Starting lava-run in a dedicated container
https://git.lavasoftware.org/lava/lava/issues/114
Work has already been done for the device support in this area. The intention is that the admins can create static udev rules which add the device to the correct container. To achieve this, the name of the container needs to be made available to the udev rule. The plan will be for lava-slave to create a file in /var/cache/lava-slave/. The file will be named according to the device hostname and will contain the container name plus some other useful data, e.g. the job ID. the udev rule can then parse this file to know which container to use. The udev rule would be triggered on each ADD. If lava-slave is run in a docker, /var/cache/lava-slave/ would need to be made available to that docker as a volume. (LAVA specifies the name of the container in advance.)
Test job to control the image to be used
The LAVA documentation will need to recommend using official LAVA Software Community Project docker images, some teams will want to build & use images based on those to help include tools which take a long time to install / build. LAVA will not be able to check the provenance of the images being used, this is a 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. lava-slave will need to handle "latest" URLs and turn it into a reproducible ID using docker inspect to get the image ID. This is to be done by passing an argument to a new lava-run option.
LAVA already outputs the version of lava-dispatcher (lava-run) in use (and other tools) and this will continue with docker.
Admins will continue to control certificates, e.g. ZMQ
Capabilities may need to be added too.
LAVA runs the container with --rm (possibly with --force too).
Releases and milestones
We have created a 2019.03 milestone which is expected to contain the work on lava-run in a separate container above. We have moved a number of issues and merge requests from 2019.02 into 2019.03 (or sometimes into .05) to get to a feasible number of changes to release 2019.02.
Adding env variables to the test shell
In combination with https://git.lavasoftware.org/lava/lava/issues/228 we will be looking at making device dictionary elements and some environment variables available inside the Lava-Test Test Definition 1.0 overlays using a test shell helper. Test writers are advised not to rely on device-specific information unless essential.
From my perspective this isn't super urgent as there is a work around
(adding a mapping in test scripts). So if it helps you delivering other features I'm OK postponing this feature.
milosz
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Lava-devel mailing list Lava-devel@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-devel
lava-devel@lists.lavasoftware.org
-
Milosz Wasilewski -
Neil Williams