Hi, Milosz,

I fully agree with you that it need take care. But when docker open these parameters to user, they surely face the same problem, but docker let user to decide. I think same thing happened to LAVA, this could be decided by lab admin which docker device or which slave could let user add which more parameters?

You know, for many scenario, it's really not an issue to consider the secure or persist, quick/easy test is the key. Even more, these things could be handled outside of LAVA.

And, if possible to add a more generic option "--extra-options" to "utils/docker.py" will more helpful. Inspired from your handing for android, we may try to put UUU action (https://git.lavasoftware.org/lava/lava/-/blob/master/lava_dispatcher/actions...) in docker just like you did for ADB, but still I haven't found a way to operate UUU in docker without `--privileged`... It doesn't work like `adb`...

I submit a ticket here: https://git.lavasoftware.org/lava/lava/-/issues/415

-----Original Message----- From: Milosz Wasilewski milosz.wasilewski@linaro.org Sent: Monday, June 8, 2020 4:20 PM To: Larry Shen larry.shen@nxp.com Cc: antonio.terceiro@linaro.org; lava-users@lists.lavasoftware.org Subject: Re: [Lava-users] [EXT] Re: docker shell cannot handle adbd.

Caution: EXT Email

On Mon, 8 Jun 2020 at 02:24, Larry Shen larry.shen@nxp.com wrote:

Thanks Antonio for the clarify.

A side question: For docker test shell, if possible add more docker options for user? E.g. bind mount, etc.

A scenario is: If we have some code needed when test, currently, we could just inject it into docker image when do docker build, or when test git clone the code from network. You know docker test shell use `--rm`, means every time, we need to git clone it, or if a small changes we need to build the image. A bind mount there to mount our code may make things easier for us?

I think you should be careful with mounting a local resource. It might lead to problems with persistence. Overall might be useful but should be used with caution. Could you report a ticket in gitlab?

milosz

-----Original Message----- From: Lava-users lava-users-bounces@lists.lavasoftware.org On Behalf Of lava-users-request@lists.lavasoftware.org Sent: Saturday, June 6, 2020 8:00 PM To: lava-users@lists.lavasoftware.org Subject: [EXT] Lava-users Digest, Vol 22, Issue 7

Caution: EXT Email

Send Lava-users mailing list submissions to lava-users@lists.lavasoftware.org

To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% 7Clarry.shen%40nxp.com%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc 2b4c6fa92cd99c5c301635%7C0%7C0%7C637272012232138191&sdata=Y8S%2BQm WD5xDzd7qj%2BrnqXnviDXBgkP61SjasdlBBiqE%3D&reserved=0 or, via email, send a message with subject or body 'help' to lava-users-request@lists.lavasoftware.org

You can reach the person managing the list at lava-users-owner@lists.lavasoftware.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."

Today's Topics:

1. Re: [EXT] Re: docker shell cannot handle adbd. (Antonio

Terceiro)

---

Message: 1 Date: Fri, 5 Jun 2020 09:26:18 -0300 From: Antonio Terceiro antonio.terceiro@linaro.org To: lava-users@lists.lavasoftware.org Subject: Re: [Lava-users] [EXT] Re: docker shell cannot handle adbd. Message-ID: 20200605122618.GA359587@linaro.org Content-Type: text/plain; charset="us-ascii"

On Fri, Jun 05, 2020 at 07:06:16AM +0000, Larry Shen wrote:

...

Hi, Milosz,

Maybe I understand wrong, but I already see there is code like next to add dynamic device node to docker container.

I tried it in manual, adb find devices after a new device node added with next code. But I don't see the docker shell try to call it with some way. What's the aim of next code if you did not want to use it? Could you double confirm internal maybe some guys is handling it, but just in process? Could you do me a favor inform me your plan if my guess is true?

I don't think people could switch from lxc to docker on android if this not support, maybe my environment wrong or anything else?

Yes, you are right. The way the docker test shell currently works won't support such a use case.

First, there was an issue with the udev rules being too strict, which was recently fixed and will be in the next release: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. lavasoftware.org%2Flava%2Flava%2F-%2Fissues%2F411&data=02%7C01%7Cl arry.shen%40nxp.com%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637272012232138191&sdata=kLSaQrGCVjw GH%2BGzNSnJjOVCatXl9JKqyL2%2B7R8SsV8%3D&reserved=0

This issue that you mention also needs to be fixed; I created an issue to track and I will work on it: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. lavasoftware.org%2Flava%2Flava%2F-%2Fissues%2F414&data=02%7C01%7Cl arry.shen%40nxp.com%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637272012232138191&sdata=i%2BwTn%2BA E7EI%2F2oqlO2xflxn6vZIh1eFelwwBmt7sAkU%3D&reserved=0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist s.lavasoftware.org%2Fpipermail%2Flava-users%2Fattachments%2F20200605%2 F741169ba%2Fattachment-0001.sig&data=02%7C01%7Clarry.shen%40nxp.co m%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc2b4c6fa92cd99c5c30163 5%7C0%7C0%7C637272012232138191&sdata=ys3%2FNV3kvzMbrIYJ8x2hydvyAnm q1A85pLc9HJK5qF4%3D&reserved=0

---

Subject: Digest Footer

---

Lava-users mailing list Lava-users@lists.lavasoftware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% 7Clarry.shen%40nxp.com%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc 2b4c6fa92cd99c5c301635%7C0%7C0%7C637272012232138191&sdata=Y8S%2BQm WD5xDzd7qj%2BrnqXnviDXBgkP61SjasdlBBiqE%3D&reserved=0

---

End of Lava-users Digest, Vol 22, Issue 7

---

---

Lava-users mailing list Lava-users@lists.lavasoftware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% 7Clarry.shen%40nxp.com%7Ca721328d010d4f6e559208d80b84c9ea%7C686ea1d3bc 2b4c6fa92cd99c5c301635%7C0%7C0%7C637272012232138191&sdata=Y8S%2BQm WD5xDzd7qj%2BrnqXnviDXBgkP61SjasdlBBiqE%3D&reserved=0

Hi, Antonio,

I see adbd restart support already ok in MR1238, thanks.

Meanwhile, I see an additional bind mount for "LAVA_DOWNLOADS", but it could not meet our requirements. So continue the question: if possible to add more bind mount for "docker test shell"?

Something like: Option 1: Let lab admin specify bind mounts in device.jinja2, then "docker test shell" could mount it? Option 2: "docker test shell" always bind mount a static "callback location", if that "callback location" exists on host, mount it. Then users could just put the things in that "callback location". Looks this limited bind mount won't bring any risk to host machine?

You know, I'm talking about "big things like some code, pictures, videos etc" which not so efficiency to be download on the fly when test start. Meanwhile, don't want to generate docker image again and again once there is something change. So, bind mount is the most convenient solution for us.

-----Original Message----- From: Larry Shen Sent: Tuesday, June 9, 2020 1:03 PM To: antonio.terceiro@linaro.org Cc: lava-users@lists.lavasoftware.org Subject: RE: [EXT] Re: [Lava-users] docker shell cannot handle adbd.

Thanks for reply, in fact what I'm talking about is not the logic correct or not, but the efficiency.

Let's suppose we need to clone a big repo(may also submodules) for about 30 minutes, then what happened if we made a update in this repo? (NOTE: frequent changes in this repo)

Solutions maybe next:

1) Separate not frequently changed parts to base image, then every time we update, we could just build a small docker image. Disadvantage: We can't determine which parts not frequently changed, so can't use it.

2) In dockerfile, clone the big repo, then every time we had changes, we need to rebuild the docker image. Here we could not use docker build cache as we need the latest repo. Disadvantage: For a small change, we need another >= 30 minutes to clone & finally get a new docker image, not so agile.

3) In dockerfile, add/copy this when docker build, then a huge build context will be tar then pass to docker build container. Disadvantage: Tar the docker build context really consume time, also not agile.

4) In docker test shell of lava, when test begins, clone the resource. As `--rm` used, the big repo not be able to be reused by next time. Disadvantage: Every time when we trigger a new test job, we need wait > 30 minutes to wait the repo ready, then start the test.

5) Have bind mount there, every time, when we update code, we just need to pull/sync the changes, this finished in seconds. Then we start test job, no additional time for user to wait. Just first time, we need to clone the whole repo, it's a one-time effort.

So, sum all, what I care is efficiency.

-----Original Message----- From: antonio.terceiro@linaro.org antonio.terceiro@linaro.org Sent: Monday, June 8, 2020 10:25 PM To: Larry Shen larry.shen@nxp.com Cc: lava-users@lists.lavasoftware.org Subject: Re: [EXT] Re: [Lava-users] docker shell cannot handle adbd.

On Mon, Jun 08, 2020 at 01:24:47AM +0000, Larry Shen wrote:

Thanks Antonio for the clarify.

A side question: For docker test shell, if possible add more docker options for user? E.g. bind mount, etc.

A scenario is: If we have some code needed when test, currently, we could just inject it into docker image when do docker build, or when test git clone the code from network. You know docker test shell use `--rm`, means every time, we need to git clone it, or if a small changes we need to build the image. A bind mount there to mount our code may make things easier for us?

I'm not sure what is the problem you want to solve here. Including code in a docker image seems to be the recommended way of using docker. If the code changes, then the image changes - that's how it's supposed to work.

Note that the fact that docker runs containers with --rm has no effect on docker images: --rm only removes the _container instance_ after it finishes running, not the image. If your code was already in the image it's not affected. If the code is cloned during the test, it is also not affected by --rm as that same container instance would not be be reused for later tests anyway.

Hi, Antonio,

I submit a MR: https://git.lavasoftware.org/lava/lava/-/merge_requests/1270 for extra bind mount of docker test shell, please have a look when you have time, thanks.

-----Original Message----- From: antonio.terceiro@linaro.org antonio.terceiro@linaro.org Sent: Monday, July 13, 2020 8:42 PM To: Larry Shen larry.shen@nxp.com Cc: lava-users@lists.lavasoftware.org Subject: Re: [EXT] Re: [Lava-users] docker shell cannot handle adbd.

On Thu, Jul 09, 2020 at 02:52:52AM +0000, Larry Shen wrote:

Hi, Antonio,

I see adbd restart support already ok in MR1238, thanks.

Meanwhile, I see an additional bind mount for "LAVA_DOWNLOADS", but it could not meet our requirements. So continue the question: if possible to add more bind mount for "docker test shell"?

Something like: Option 1: Let lab admin specify bind mounts in device.jinja2, then "docker test shell" could mount it?

Option 2: "docker test shell" always bind mount a static "callback location", if that "callback location" exists on host, mount it. Then users could just put the things in that "callback location". Looks this limited bind mount won't bring any risk to host machine?

You know, I'm talking about "big things like some code, pictures, videos etc" which not so efficiency to be download on the fly when test start. Meanwhile, don't want to generate docker image again and again once there is something change. So, bind mount is the most convenient solution for us.

Yes, I guess we could do that. I like your option 2 more: a fixed directory in the host (configurable, but fixed at runtime) that gets bind mounted at a also well known location inside test containers. Feel free to propose a MR.