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?
- /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?
Regards
Steve