On Mon, Jul 13, 2020 at 05:50:46PM +0000, Stephen Lawrence wrote:
Hi,
-----Original Message----- From: Stephen Lawrence Sent: 13 July 2020 16:29 To: 'Antonio Terceiro' antonio.terceiro@linaro.org Cc: lava-users@lists.lavasoftware.org; gandersson@genivi.org Subject: RE: [Lava-users] fastboot in docker support
Hi,
-----Original Message----- From: Antonio Terceiro antonio.terceiro@linaro.org Sent: 13 July 2020 13:32 To: Stephen Lawrence stephen.lawrence@renesas.com Cc: lava-users@lists.lavasoftware.org; gandersson@genivi.org Subject: Re: [Lava-users] fastboot in docker support
[snip]
For docker to work for this from a dispatcher running inside docker, you need:
- lava-dispatcher-host installed and configured on the host OK
This I need to check as I am not familiar with the name. If it is a standard part of the dispatcher then it should be there but I will check.
Checking in the dispatcher docker I can confirm it is present. Both the lava_dispatcher_host and lava_dispatcher_host-2020.7.egg-info directories are present in the python3 dist-packages.
Harder to comment on configuration. Did you have a specific point of failure in mind?
There was a typo in my message: s/host OK/host OS/ i.e. lava-dispatcher-host needs to be installed and configured in the host *OS*. If you are using Debian then just having the package installed is enough as it does the setup for you
Otherwise you need to run `lava-dispatcher-host rules install` to have the udev rules installed.
- /var/lib/lava/dispatcher/tmp and /run/udev from the host OS bind mounted in the dispatcher container
Yes we have both.
- the docker socket from the host OS shared with the dispatcher containers, so that the containers started by the dispatcher are siblings of the dispatcher container and not its children.
This I think we saw this from our probing and testing of the code so should be the case, but again no harm in confirming.
I was pretty certain but have confirmed that yes the socket is shared into the dispatcher container: https://github.com/kernelci/lava-docker/blob/b57379c6b204870a568ccc7adcad171...
I went back and retested 'deploy to fastboot' under 2020.07 in case the behaviour changed from 2020.05. It still works so the deploy to fastboot specific docker run implementation that still passes the usb device works: https://lava.genivi.org/scheduler/job/1057
Therefore on a base level the dispatcher docker is allowing the host and device to find each other and the failure appears to relate to the different discovery and device passing code used by test/deploy to downloads. Could the new code bring requirements to the android-tool docker not needed before?
Yes, they work a bit differently.
For flashing lava itself just waits for the device to be available via udev, and since you have /run/udev mounted (and I assume also /dev) in the container it works because the device node is passed excplitily in the docker run call.
For the docker test action, first the docker container running your tests is spawned. we can't just pass the device node in the docker run call, because your tests can e.g. reboot the device, and we need it to become available again after rebooting, getting a new device number etc.
Therefor, for this case the device is shared dynamically with the container by lava-dispatcher-host, which is triggered from the udev daemon. Thus you need lava-dispatcher-host and its udev rules in the host operating system.