Daniel P. Berrangé <[email protected]> writes:
> On Wed, Oct 14, 2026 at 02:56:46PM -0300, Fabiano Rosas wrote:
>> Daniel P. Berrangé <[email protected]> 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
