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.