QEMU-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Fabiano Rosas <farosas@suse.de>
Cc: qemu-devel@nongnu.org, peterx@redhat.com, mjt@tls.msk.ru
Subject: Re: [RFC] container images for migration-test
Date: Thu, 15 Oct 2026 08:17:23 +0100	[thread overview]
Message-ID: <atB-A09ZuRod1Qvo@redhat.com> (raw)
In-Reply-To: <87jynkmaht.fsf@suse.de>

On Wed, Oct 14, 2026 at 02:56:46PM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Mon, Sep 14, 2026 at 08:58:09PM -0300, Fabiano Rosas wrote:
> >> Hi, I just wanted to share and ask for feedback on some container images
> >> I've been building as part of my testing of migration pull-requests.
> >> 
> >> From a Dockerfile from ./tests/docker/dockerfiles/ I'm producing the
> >> following:
> >> 
> >> $ docker images
> >> qemu-build-base:11.0.0                        b6efa198e93a        5.8GB
> >> qemu-rootfs-base:11.0.0                       72bcb5418f4d       4.08GB
> >> qemu:11.0.0                                   018a3f0f4dcc          2GB
> >
> > snip
> >
> >> 2) Neither the QEMU build nor the distro repos are reliable enough to
> >> allow me to just "go back in time" and rebuild at any moment, I need to
> >> keep the artifacts cached to avoid rebuilding. Otherwise it comes time
> >> to send a PR and I discover that some python piece has changed or the
> >> distro messed up the older repository.
> >
> > Yes, in general building old QEMU on new distros periodically
> > hits trouble.  If building old QEMU, better reliability is
> > achieved by using a distro release that was from the same
> > timeframe as QEMU.  Is using containers targetting such old
> > distro versions not an option ? The tests/docker/dockerfiles
> > from the old QEMU branch ought to work ?
> >
> 
> Yes, I'm doing just that. Some tweaks are needed still. For instance, my
> script has something like this:
> 
>   dockerfile="tests/docker/dockerfiles/opensuse-leap.docker"
> 
>   sed -i 's/ncurses-devel//' $dockerfile
> 
>   if [ "$tag" = "10.1.0" ]; then
>       sed -i 's/libLLVM19//' $dockerfile
>   fi

If that's needed, shouldn't we patch the QEMU stable branch ? I
would have thought that would be a problem for doing releases on
stable if the containers have bugs ?

> > How far back in time do you need/want to go for migration
> > testing ?  Is it sufficient to merely target versions for
> > which mjt is still doing active maint work, so we can
> > expect the containers to still work.
> >
> 
> I'm currently testing against the previous 3 releases. I think 2
> releases is probably enough.

I guess if we test   X -> Y and then later test Y -> Z, then
we have transitively validated X -> Z. So in theory only 1
historical release is enough, but it makes sense to test one
or two more variants just in case.

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



  reply	other threads:[~2026-10-15  7:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 23:58 [RFC] container images for migration-test Fabiano Rosas
2026-10-08 23:40 ` Peter Xu
2026-10-09 12:58   ` Fabiano Rosas
2026-10-09 15:09     ` Alex Bennée
2026-10-09  0:48 ` Pierrick Bouvier
2026-10-09 19:36   ` Pierrick Bouvier
2026-10-10 23:19   ` Pierrick Bouvier
2026-10-12  8:18 ` Daniel P. Berrangé
2026-10-13 22:51   ` Pierrick Bouvier
2026-10-14 17:56   ` Fabiano Rosas
2026-10-15  7:17     ` Daniel P. Berrangé [this message]
2026-10-15 12:45       ` Fabiano Rosas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atB-A09ZuRod1Qvo@redhat.com \
    --to=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=mjt@tls.msk.ru \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox