Re: [Qemu-devel] [PATCH RFC v4 0/4] docker: Support building qemu-user powered docker test images

["Alex Bennée" <alex.bennee@linaro.org>]

Fam Zheng <famz@redhat.com> writes:

> Alex,
>
> This is the result of my fiddling around docker + qemu-user in the weekend. It
> can do most of the work except the injection of qemu-user binary from host
> build.  We can try to integrate your "docker.py update" into Makefile to do
> that, but an open question is how to handle the dependency cleanly: we
> intentionally allow "make docker-foo" w/o configure or build, but the qemu-user
> case is very different.

I think it is certainly worth keeping the ability to inject qemu into
the docker container. While for a random build-on-other-arch type setup
we can rely on the docker distro's implementation for builds the other
use case is testing the current qemu still works for a linux-user type
setup.

> The major change is using "FROM debian" and build thing in the container so
> that qemu-arm, fakeroot and debootstrap are not required on the system (the
> docker file installs qemu-user-static). This way the pre script is not needed.
>
> The upside is debootstrap can make use of docker cache, so updating is easy,
> but we have to handle chroot in run script, before running the test
> command.

But really the native Debian host doesn't take the time to setup, it is
the debootstrap that chugs along. Until docker hub starts supporting multiple
architecture docker images (which I believe is coming) it doesn't make
much difference to the image build time.

> This seems cleaner in host side dependencies to me, what do you think?

I think we should support both. Keeping all the dependencies inside the
docker environment works really well for keeping everything host
distribution agnostic and is probably the way forward to support "cross"
build setups from the Makefiles.

One advantage of the pre script approach is we can have a generic recipe
for Debian which allows the user to spin up various architectures just
by tweaking the environment variables. And from my point of view one of
the drivers for my patches was being able to setup rootfs without
complicated bind mounts and chroots so I do like "docker run" dropping
directly into a translated shell.

Is there a similar boot strap we can use to setup cross fedora images?

Maybe we should merge the .py changes and your dockerfiles in
test/docker/dockerfiles and my general purpose (but requiring host
requirements) into contrib/docker?


>
> Fam
>
> Fam Zheng (4):
>   docker: More sensible run script
>   docker: Fix exit code if $CMD failed
>   docker: Support "QEMU_CHROOT" in dockerfiles
>   docker: Add debootstrap-arm image
>
>  tests/docker/Makefile.include                   |  5 ++--
>  tests/docker/dockerfiles/debootstrap-arm.docker | 35 +++++++++++++++++++++++++
>  tests/docker/run                                | 28 +++++++++++++++++---
>  3 files changed, 62 insertions(+), 6 deletions(-)
>  create mode 100644 tests/docker/dockerfiles/debootstrap-arm.docker


--
Alex Bennée