On Tuesday 30 January 2018 04:47 AM, Kevin Hilman wrote:
Steve McIntyre steve.mcintyre@linaro.org writes:
We're already working on this, mocking up bits of the lxc interfaces so they'll work transparently in a docker. It's an obvious thing to go with the the docker-dispatcher. See
https://git.linaro.org/lava/lava-lxc-mocker.git/
for initial development work. Senthil can tell you more...
This is tracked via https://projects.linaro.org/browse/LAVA-1201
Hmm, that's an interesting idea, and I understand the need to pretend/fake that LXC exists if you already have jobs that use LXC.
As you can see from the above card that is the basic idea where we do not want the lava-master to know what kind of worker is running.
I don't want my jobs to pretend they're in an LXC container when they are not, and never will be because I'm already running LAVA inside a container.
Such an use-case is the idea behind the text explained in "TBD" section of the above card. In this case we plan to control it via two things:
1. Absence of LXC protocol related content in the job yaml. 2. A setting in lava-dispatcher that governs whether running fastboot and adb is allowed directly on this dispatcher. This is required for LAVA instances that does not run within virtualized containers and hosts more than one DUT.
The above implementation will require changing things like:
* Provide equivalent pipeline actions that does not use an LXC connection or lxc-attach * Constructing a different job action pipeline from what will be used for a normal LXC protocol based job.
Though we started with the above idea, later our design discussions led to lava-lxc-mocker.
We will re-iterate to see if we can support new jobs that will completely use direct access without LXC, which will be taken up once we have lava-lxc-mocker use case done, which is still valid for providing compatibility for reusing jobs that uses LXC protocol.
Thank You.