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
On Fri, Jul 10, 2020 at 06:28:35PM +0000, Stephen Lawrence wrote:
Hi Antonio,
-----Original Message----- From: Antonio Terceiro antonio.terceiro@linaro.org Sent: 06 July 2020 13:04 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]
Antonio wrote:
FWIW they are up in merge request 1238: https://git.lavasoftware.org/lava/lava/-/merge_requests/1238
I am running the changes by updating to the 2020.07 Linaro docker image.
I found that in the simple case my jobs will now execute the docker container, e.g: https://lava.genivi.org/scheduler/job/1047
but when I do any actual fastboot work from the container the host waits for the
device
and eventually times out, e.g: https://lava.genivi.org/scheduler/job/1048#L245
I notice that no device is passed in the docker run. Is that expected behaviour?
It is now. the device is not not passed in the docker run command line, but shared with the container dynamically via lava-dispatcher-host either right at the beginning, or whenever the device appears to udev.
OK. Thank you for the summary.
I need to investigate further Monday but I wanted to ask if your udev changes bring
any
new requirements to device configuration such as device or device-type templates?
You should not need any changes to the device config.
OK. I wanted to check that off as a possible cause.
You said you are running the dispatcher in docker; how exactly are you doing that?
We are running the linaro docker image for 2020.07 via a fork of lava-docker commit b57379c6 [1]. [1] https://github.com/kernelci/lava-docker/commit/b57379c6b204870a568ccc7adcad1...
The fork carries instance specific changes for things like the DUTs, method of mounting artifacts etc. I would point you at the source rep but it contains some admin details. If there is anything you can't get from the public running instance then please ask.
You can find the "android tools" docker image definition here [2].
[2] https://github.com/gunnarx/linux-cip-ci/tree/master/android-tools-docker
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.
- /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.
Does that make sense? I have it on my TODO list to properly document this for the next release, hopefully I will be able to do it in a more comprehensible way.
I think so. I think we are close, the 'simple deploy' case fastboot comms works after all, it is the differences in behaviour between that and the boot and test docker handling that is tripping us up. We've been trying to compare against what few public instances of AOSP Android 10 we've found for something that might have been missed in the absence of a hard requirements list. So your reply helps. udev rules were another aspect I was wondering about.
Having written that the 'simple deploy' fastboot comms works I realise that was for 2020.05. I should also reconfirm that with 2020.07.
Regards
Steve