Re: [RFC] container images for migration-test

[Fabiano Rosas <farosas@suse.de>]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

Right, but that's not simply regular development work touching the
dockerfiles and they sitting there just working. I see the overall
benefits of having the dependencies listed in a dockerfile under our
control, but for this particular use-case it's a bit of a pain point.

To be clear, this is not an issue I'm particularly concerned with, we
can fix it in stable or hack away in a script like I did. And issues
like this should be on the rarer side.

I'm more interested in the other part, which is having some infra that
can take whatever base image and produce a container that's standin for
the actual qemu binary. This allows quick switching of QEMU release
versions for testing and debugging and keeps the migration testing
concerns separate.

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

Yes, but sometimes we have weird compatibility knobs, I feel more
comfortable with more testing. They're quick tests, it's not too much
work. I usually run migration-test (small set) for every PR with:

x86_64: dev -> X, dev -> X-1, dev -> X-2
        dev <- X, dev <- X-1, dev <- X-2

s390x: dev -> X, dev -> X-1
       dev <- X, dev <- X-1

pcc64le: dev -> X
         dev <- X

But there's also testing in the sense of working with bug reports,
debugging and development in general. So having a few versions available
improves productivity.

> With regards,
> Daniel