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