On Thu, 21 Feb 2019 at 11:13, Karsten Tausche karsten@fairphone.com wrote:
Hi Neil,
I'm replying to this older thread regarding questions that came up for me in a recent mail: https://lists.lavasoftware.org/pipermail/lava-users/2019-February/001693.htm... and the issue you linked: https://git.lavasoftware.org/lava/lava/issues/114
On 24.01.19 16:06, Neil Williams wrote:
Don't obsess about the LXC either. With upcoming changes for docker support, we could remove the presence of the LXC entirely. The LXC with android devices only exists as a unit of isolation for the benefit of the dispatcher. It has useful side effects but the reason for the LXC to exist is to separate the fastboot operations from the dispatcher operations.
What exactly is the envisioned approach for AOSP testing in LAVA? Is it that LXC gets replaced by (user) docker containers?
Either or both, depending on how each instance is configured.
At the moment, only LXC support is actually working. The docker support is in development.
The principle problem with LXC is that the tooling inside the LXC needs to be installed and configured afresh each test job. Docker would solve that but that is about the only benefit - speed of operation and more direct control over the tooling environment.
In earlier messages I got the impression that the containers are removed entirely.
If you use LXC on bare metal, you just get LXC support. This is what is being used for all production testing of AOSP - in fact, it's what is being used for all production testing of any fastboot device. This issue isn't about AOSP as such. It is fastboot as a bootloader which is the restriction. Test jobs which boot OpenEmbedded or Debian on an X15 or hikey must still use LXC - unless the bootloader is changed from fastboot to U-Boot.
If you use LXC in an official LAVA Software Community Project docker image, then the LXC functionality is replaced by lava-lxc-mocker and the job works as normal, using the docker container instead of an LXC. This has persistence issues which are to be addressed in https://git.lavasoftware.org/lava/lava/issues/114 - the only container would be docker.
If you only ever use Docker, then the lava-lxc protocol blocks can be removed from your test job submissions. This has only been tested in developer situations and needs more work to be used more widely.
Thus, when it becomes fully supported to do testing of fastboot devices using Docker, then there will be no LXC in use. Only the docker image(s) will exist.
However, labs will retain the ability to support both options. It depends how each lab configures their own workers.
So don't obsess about LXC specifically but do start your work with fastboot devices using LXC. In time, Docker support will become available to replace the LXC but you will retain the choice of which to use.
If not, will there still be one container per test job (thus per DUT)? How is isolation and scalability achieved for fastboot and adb, especially regarding the issues listed here: https://master.lavasoftware.org/static/docs/v2/integrate-fastboot.html ?
That is the task of https://git.lavasoftware.org/lava/lava/issues/114
Do you expect that changes on the test jobs/shells/scripts will be required to be compatible with the new approach, especially for MultiNode testing?
Not mandatory, no.
However, in the course of time, if the usage of LXC drops as the use of Docker increases for these test jobs, then changes can be made. Essentially, the initial test jobs will carry unused blocks (the lava-lxc protocol definitions) which will be mocked up by lava-lxc-mocker. The only changes expected will be in the test job submissions and through lava-lxc-mocker, we aim to have the ability to submit the same LXC-based test job to a worker using LXC as to a worker using Docker.
MultiNode testing of AOSP is not commonplace, principally because AOSP does not provide a POSIX shell on serial by default.
For any further discussion of topics like this, please subscribe to and post to the lava-devel mailing list.
Thanks, Karsten