Re: [PATCH 3/7] tests/lci/refresh: add parameter to override container registry

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Sep 22, 2026 at 12:03:59PM -0700, Pierrick Bouvier wrote:
> On 9/22/2026 12:01 PM, Daniel P. Berrangé wrote:
> > On Tue, Sep 22, 2026 at 11:33:47AM -0700, Pierrick Bouvier wrote:
> >> On 9/22/2026 11:29 AM, Daniel P. Berrangé wrote:
> >>> On Tue, Sep 22, 2026 at 11:22:43AM -0700, Pierrick Bouvier wrote:
> >>>> On 9/22/2026 11:04 AM, Daniel P. Berrangé wrote:
> >>>>> On Tue, Sep 22, 2026 at 06:55:18PM +0100, Daniel P. Berrangé wrote:
> >>>>>> On Mon, Sep 21, 2026 at 11:14:54PM +0000, Pierrick Bouvier wrote:
> >>>>>>> We'll use this in next patch to switch FROM docker.io/library to
> >>>>>>> docker.io/amd64. It would not make sense to add a new target to
> >>>>>>> libvirt-ci for this, since it's just a variant of an existing target.
> >>>>>>> Simply replace container registry with arch specific one.
> >>>>>>
> >>>>>> We shouldn't need to add new targets to lcitool for this,
> >>>>>> rather it would be enhanced to include a list of arch
> >>>>>> specific container images.
> >>>>>>
> >>>>>> eg in
> >>>>>>
> >>>>>> https://gitlab.com/libvirt/libvirt-ci/-/blob/master/lcitool/facts/targets/debian-13.yml?ref_type=heads
> >>>>>>
> >>>>>> We would extend:
> >>>>>>
> >>>>>>   containers:
> >>>>>>     base: docker.io/library/debian:13-slim
> >>>>>>
> >>>>>> to allow for
> >>>>>>
> >>>>>>   containers:
> >>>>>>     base: docker.io/library/debian:13-slim
> >>>>>>     aarch64:  docker.io/amd64/debian:13-slim
> >>>>>>     ...more...
> >>>>>>
> >>>>>> such that we default to the 'base' image name, unless
> >>>>>> there is an arch specific name defined. That would be
> >>>>>> a fairly quick extension to impl in lcitool.
> >>>>>
> >>>>> Quicker than I thought.... take a look at this, which
> >>>>> I think will enable you to drop this patch and the
> >>>>> next one and get the same end result:
> >>>>>
> >>>>>   https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/588
> >>>>>
> >>>>
> >>>> Very quick indeed, good job :)
> >>>>
> >>>> IIUC, when no host-arch is given, we keep on using base, but in case
> >>>> user specifies -host-arch, in this case we use one of specialized image
> >>>> (if available)?
> >>>
> >>> Actually it is indepedent of --host-arch.
> >>>
> >>> If --host-arch is omitted we default it to what uname() reports,
> >>> and the result then goes into the container image lookup, which
> >>> is optionally specialized per arch.
> >>>
> >>
> >> It works for QEMU needs, but would that be a safe default for other
> >> users of lcitool?
> > 
> > Yes, I think it ought to be OK.  If something unexpected crops up
> > we'll deal with it as needed.
> > 
> >> Technically, you can write portable Dockerfiles between arch. Our
> >> current debian-all-test is kind of an example of it (ignoring the change
> >> this series does).
> > 
> > True, but lcitool isn't guaranteeing it can be done, as we allow
> > output to filter per-arch, so there's always the risk of getting
> > the libpmem situation - IIRC it hits with 'xen-devel' too as some
> > arches lack Xen.
> > 
> > So realistically I think we would say lcitool container outputs
> > are arch specific.
> >
> 
> I'm good with this assumption. There are always small details that makes
> it hard to have truly portable Dockerfiles.
> 
> I'll wait for PR to be merged on libvirt-ci, then update current series
> with it for v2.

FYI, it is merged now.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|