Hi, guys,

I have a question after listen Docker feature for Android testing, and the question is a little long.

1. I want to say sorry that I haven’t ever tried it on android because currently not urgent for us to switch from lxc to docker.

But my real question is related to this feature at least I think.

2. The whole story is:

We have a device which use the “tftpboot(deploy) -> nfs(boot) -> shell(test)” mode to test, that’s ok.

But now we have a team which for their testcases, they need to define other logic which behavior totally different with current lava solution.

There is legacy code on pc which we want to reuse, so the quicker way for us is to use docker device, in it we could do anything to control the device.

What we tried is:

- Deploy (to: docker)

- Boot (method: docker)

- Test

It’s ok, as you see we could use the connection from boot in test. But as you know, not all device type accepts docker actions.

Then, I find the option after you give the presentation in linaro tech share, use docker test.

3. I tried the v2020.02 release, it’s ok to use next with any device type in our job to do my things.

- test:

    docker:

      image: ubuntu:18.04

Although some android related log printed like “- ANDROID_SERIAL='xxx'”, but I can bear.

4. Things broken when you improve this feature in v2020.04, you add next in pipeline:

WaitDeviceBoardID(self.get_board_id()

Then, the pipeline will have to wait for a udev event, but in our case, we don’t have, we control device with “remote telnet device”, then job hang.

5. So, my question here is: “What’s the roadmap of this docker test action”?

a) Is it just for android scenario?

b) Why we can’t make it works for more common scenario?

My opinion here is: with this docker test action, we even no longer need the old “docker deploy + docker boot”?

c) For this docker test, most of docker operation was written fixed in docker test, if possible to add in some place which user could configure? Like, if I want to add “-t”, I can’t control that although you define the interface in “DockerRun” with “def tty(self):”, and others like more docker bind mounts etc?

6. BTW, a side question related to android (As definitely someday we need to switch from lxc to docker, I use this chance to ask the question).

What will happened if there is adbd restart or pdu reboot in “docker test”? You add “—device” for the usb bus (I’m not sure, just think it same way as lxc), but during adbd restart or pdu reboot, the usb bus will surely changes. I didn’t see docker has such kinds of ability to renew the “—device”. How would that happen? Sorry again, I haven’t tired, just want to know the mechanism.

7. Anyway, currently what I care about is the roadmap of “docker test”.

If your final direction is to make the “docker test” more common, then we are OK currently “STICK ON 2020.02”. If just for android & “WaitDeviceBoardID” had to be here without any control by user, then we will give up this solution & try to find another way to reuse the device in LAVA?

Your direction matters our next step!

8. Finally,

Any other suggestion for our scenario which I described in item 2?

Regards,

Larry