[libvirt-jenkins-ci PATCH] guests: allow for container image inheritance

[Daniel P. Berrangé]

On Wed, Apr 29, 2020 at 11:10:41AM +0200, Andrea Bolognani wrote:
> 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.

I think this problem is tangential to container inheritance and so
doesn't need to be dealt with here.

Instead, it should be solved by simply defining another project
"libvirt-devel", or "libvirt-dist" which pulls in the pre-built
distro packages for libvirt.

> 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.

I'm not really experiencing this as a painpoint from the container CI
side.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|