[Buildroot] [PATCH 1/1] support/testing: add lxc test

Thomas Petazzoni thomas.petazzoni at bootlin.com
Sat Nov 9 14:05:46 UTC 2019


Hello Patrick,

On Thu,  7 Nov 2019 17:48:04 +0100
Patrick Havelange <patrick.havelange at essensium.com> wrote:

> The test starts a simple container with an iperf3 server.
> The container is using the tini init system, with a shared rootfs.
> An iperf3 client is started from the host to check that the container
> is really up and running.
> 
> Signed-off-by: Patrick Havelange <patrick.havelange at essensium.com>

Thanks for your contribution. I don't have a lot of very definitive
feedback, more some general thoughts.

First of all, what was the idea behind the use of iperf3 ? Is it just a
mean to make sure that both the container and host can communicate, and
that the container runs fine ?

Another question is about the shared rootfs situation: if I understand
correctly, the container runs with the same rootfs as the host.
Recently, Carlos Santos (in Cc), submitted a patch "package/test-vm: a
virtual machine image to  test libvirt", which builds a separate rootfs
image to run as a VM using libvirt. Shouldn't we standardize a bit how
the test cases will test things such as lxc/libvirt, and try to use
more or less the same strategy/logic to build the image executed inside
the container or VM ?

Note: this comment is really to open up the discussion on this topic.
Perhaps we will decide that what you did is good enough, and can
possibly be improved later.

> +    def run_ok(self, cmd):
> +        full_cmd = "sh -c '{}'".format(cmd)

Why is running through "sh -c" necessary ?

> +        out, exit_code = self.emulator.run(full_cmd, 120)
> +        self.assertEqual(exit_code, 0)

This seems like a useful helper method, perhaps we should have it in
the emulator class, and make use of it in other tests ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


More information about the buildroot mailing list