Re: [libvirt-jenkins-ci PATCH] guests: allow for container image inheritance
On Tue, 2020-03-31 at 15:28 +0100, Daniel P. Berrangé wrote:
Currently when creating a Dockerfile for a container, we include the
full set of base packages, along with the packages for the project
itself. If building a Perl binding, this would require us to install
the base package, libvirt packages and Perl packages. With the use
of the "--inherit libvirt-fedora-30" arg, it is possible to have a
dockerfile that only adds the Perl packages, getting everything
else from the parent image.
For example, a full Dockerfile for libvirt-go would thus be:
FROM libvirt-centos-7:latest
RUN yum install -y \
golang && \
yum autoremove -y && \
yum clean all -y
Note there is no need to set ENV either, as that's inherited from the
parent container.
I marked this for review and then kept forgetting to get around to
it, sorry!
I like the idea of reusing existing images, as the layering would
result in significant savings when it comes to disk space and fetch
times.
However, as we discussed in the past, there are two possible
scenarios for subprojects such as libvirt-go:
* include dependencies for both libvirt and libvirt-go, then build
both projects in the resulting container;
* include dependencies for libvirt-go along with distro-provided
packages for libvirt, and only build libvirt-go.
This would cover the former case, but not the latter one. And, if I
remember correctly, libvirt-go was one of the projects that would
benefit more from the latter, because it's supposed to be buildable
against various versions of libvirt.
So what I think we need is an additional flag that can be used to
choose one of the two possible behaviors. This wouldn't be limited
to the Dockerfile generator, since (unlike inheritance) it can apply
also to VM management.
As an additional point, we really need to figure out a good way to
store dependencies between projects into lcitool itself, so that you
can tell it that you're interested in building eg. libosinfo and it
will automatically take care of making osinfo-db-tools and osinfo-db
available to you, either by installing the binary packages or their
build dependencies. This is not a strict requirement for container
inheritance, I think, but the more we go on the more this limitation
is becoming painful.
--
Andrea Bolognani / Red Hat / Virtualization