Steve McIntyre steve.mcintyre@linaro.org writes:
On Fri, Jan 26, 2018 at 10:37:16AM -0800, Kevin Hilman wrote:
When using LAVA inside a docker container, the LXC support adds lots of unnecessary overhead since the docker images are already made to include the necessary tools. So having another container is pointless. Even worse, LXC doesn't work inside docker anyways.
The LXC support should be made optional for a given LAVA install.
Until LXC can be disabled, projects like lava-docker[1] simply cannot support fastboot devices which is a major problem.
Hi Kevin,
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...
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.
However, for LAVA installs that have never used LXC (for multiple reasons), it adds yet another layer of confusion (and potential bugs) that is not needed.
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.
In addition, I'm not convinced that faking an LXC container is actually a good idea and don't understand how you expect to ensure compatibility for jobs that are expecting to be virtualized (think virtualized networking?) Anyways, sounds like a can of worms to me.
We have a growing base of users for lava-docker, and have never (and will never) support LXC jobs, so it makes a lot more sense to have an option to completely disable LXC support.
Thanks,
Kevin