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