On 30 January 2018 at 01:41, Senthil Kumaran S <senthil.kumaran@linaro.org> wrote:
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.


Just to mention here, the mockup support is for compatibility when kernel engineers want to reproduce a LAVA test job on a local device *without* making lots of changes to the test job that would potentially change the behaviour being triaged. e.g. when a regression is spotted in LKFT on a device which needs LXC support on LKFT. In this situation, the engineer has the choice of using docker (with a slight but known & reproducible variation from LKFT) or setting up an instance to use LXC - without needing any changes in the test job submission and only minimal changes in the device configuration to account for local PDU ports etc.

It's a different use case from yours where the test jobs being submitted can be designed to not need LXC in the first place. The test job YAML will be very different from the first use case.

As Senthil outlines, we are looking at implementing support for both use cases. 
 
> 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.
--
Senthil Kumaran S
http://www.stylesen.org/
http://www.sasenthilkumaran.com/


_______________________________________________
Lava-users mailing list
Lava-users@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lava-users




--