test: docker: Support sharing /dev nodes using --mount docker option
In device type template, one can set: actions: test: methods: docker: share_devices: direct share_device option value can be: * udev (default, in case the value is not set or empty) - previous behavior, rely on udev event forwarding, which requires additional software running on the host (e.g. lava_dispatcher_host). * direct - pass device nodes on docker command line using --mount option (a more obvious --device option is not used, because it doesn't allow device name to contain ':', which is otherwise often the case). Only real device nodes are shared, symlinks (as usually created by udev on the host) aren't. * direct-symlinks - like above, but symlinks are shared too. Note that such symlinks become real device nodes in the container, which may pose problems with some software. (E.g. if software blindly expects a particular node to be a symlink, and calls readlink() on it. This was seen e.g. with mbedOS tools). Direct sharing of the devices is mostly implemented by 2 reasons: 1. When LAVA itself runs in a docker container(s), it's yet an open question how to perform udev forwarding (lava_dispatcher_host isn't currently a part of the official docker-compose setup for LAVA). 2. Even if forwarding works, it apparently requires udev to be running in a container to be the receiving side of this forwarding. But that's oftentimes not the case (udev is not included in docker images), which would require patching such docker images specifically for LAVA, which is not always practical. So, choice of sharing device nodes using native docker means is provided. This isn't fully optimal/general solution either, e.g.: a) it apparently won't work with dynamically appearing/disappearing device nodes; b) there're issues with symlinks, device nodes containing ':', and capabilities/permission required to access them (--device doesn't work with ':' in device names, so we have to use --mount instead; but mount requires using --privileged for most operations on the device nodes, while --device would require only particular --cap-add option). That said, with these new options, there's not a good inventory to solve different usecases, with this fairly peculiar area of operating on device nodes in docker containers, which is kind of fringe area, lying outside the original docker usecases, and which still requires further evolution upstream or robust external tools (like lava_dispatcher_host, which itself doesn't cover all the usecases yet). Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Status | Name | Job ID | Coverage | ||||||
---|---|---|---|---|---|---|---|---|---|
Test | |||||||||
passed | dispatcher-debian-10 |
#133454
amd64
|
00:02:26
|
|
|||||
passed | dispatcher-debian-11 |
#133456
amd64
|
00:02:26
|
|
|||||
passed | server-debian-10 |
#133455
amd64
|
00:02:57
|
|
|||||
passed | server-debian-11 |
#133457
amd64
|
00:05:02
|
|
|||||
Analyze | |||||||||
passed | bandit-sast |
#133458
amd64-dind
|
00:00:59
|
|
|||||
passed | black |
#133461
amd64
|
00:00:50
|
|
|||||
passed | code_quality |
#133462
amd64
|
00:00:26
|
|
|||||
passed | codespell |
#133467
amd64
|
00:00:21
|
|
|||||
passed | coverage |
#133463
amd64
|
00:07:00
|
61.05% |
|
||||
passed | dockerfiles |
#133464
amd64
|
00:00:19
|
|
|||||
passed | eslint-sast |
#133459
amd64-dind
|
00:00:25
|
|
|||||
passed | pylint |
#133466
amd64
|
00:03:20
|
|
|||||
passed | schemas |
#133465
amd64
|
00:00:34
|
|
|||||
passed | semgrep-sast |
#133460
amd64-dind
|
00:01:11
|
|
|||||
Build | |||||||||
passed | debian/10 |
#133469
amd64
|
00:01:45
|
|
|||||
passed | doc |
#133468
amd64
|
00:00:37
|
|
|||||
passed | docker-amd64-dispatcher |
#133919
amd64-dind
|
00:01:50
|
|
|||||
passed | docker-amd64-server |
#133471
amd64-dind
|
00:03:35
|
|
|||||
failed | docker-amd64-dispatcher |
#133470
amd64-dind
|
00:01:57
|
|
|||||