Pierrick Bouvier <[email protected]> writes: > This series was inspired by a recent post from Fabiano to provide container > images for migration tests: > https://lore.kernel.org/qemu-devel/[email protected]/T/#m353f119dc1a24fa437dde8a96d1891629e64303c > > The idea to be able to build and run any QEMU (past) release with containers > was > in my mind for some time, so I gave it a shot. Finally, it was easier than > expected to obtain a single dockerfile (with a few hacks) that works over all > our releases. >
Good stuff, thanks for this work. I'm just not sure how much of it fits upstream in the current shape, let's discuss... You say this was in your mind for a while, could you elaborate a bit on how you think this could benefit the project? To be clear, my use-case is simply to produce a few containers for testing migration on my workstation. Your series can help a lot with that, but from my point of view, some parts are clearly extra and some are missing. Also beware that what you're touching here is both "infrastructure" and "publishing". This has implications for how people consume the work of the project. There's a chance that people see this as "official QEMU containers" and try to use them in all sorts of weird scenarios that we as a community are not prepared to maintain. You might get some push-back on that basis. > The oldest functional distro we can find nowadays is ubuntu 12.04. Because of > this, the oldest QEMU release we can build is v0.12.0. Previous ones require > an > environment we can't get easily today. > I think the ability to go all the way back is very cool, but unless we want to look at this from a archival or heritage perspective, I'd say there's a line somewhere to how old we should go. I don't see an use-case for very old binaries. Even knowing if they still work would already incur in a maintenance cost. > Images have the absolute minimal content possible. It's only qemu binaries, > artifacts (roms, keymap, ...), and libraries. There is no shell or any other > tool included. As a result, images have a size from 149MB (v0.12.0) to 1.48GB > (v11.1.2). > No shell means the first thing to do if one wants to debug the image is to rebuild with a shell in. Not sure how frequent it will be, maybe it's ok like this. > This series adds 3 pieces: > - a unique dockerfile to build any QEMU release. User has to provide an > explicit > Ubuntu version when building a given QEMU version. This is the tricky part. We'll be carrying code (script+dockerfile) that only works on master. If we tag today and tomorrow the old distro repo breaks, we obviously cannot fix it retroactively. So we need to be careful of where we direct the maintenance effort. 1) I'd suggest first of all to keep the release image entirely separate from the ubuntu image. Treat release.docker as we treat the other dockerfiles and update it to work for the current release without looking at past ones. Have it clone, checkout, build and gather deps. Allow the configure to be tweaked via parameter in case we need to disable something in an older build. The script would then build a distro image (or dockerfile) with the knowledge that it has about ubuntu depending on the QEMU tag vs. ubuntu version combination. This would allow us to track the cludges more precisely instead of "some ancient distro" as the dockerfile currently says. This is more of a layering concern and how easy it will be to drop/add version-specific fixes. 2) I wonder if the usage of apt-get build-dep might be a convenience trap. In theory, some of the adaptations that are required (such as tweaking dependencies) have already been done by us when working on that development window. If we take the dockerfiles from the git tag, those changes don't need to be done again and for the issues that didn't exist at the time, we can map them to the git tag instead of ubuntu version; (we tend to know more about QEMU releases than ubuntu releases). Another issue with buid-dep is that it lists _ubuntu package_ dependencies. The distro can change how it builds the package without us noticing. There is already some work done by lcitool, I imagine that it would then be duplicated. Or worse(!) be different because build-dep might be listing way more packages that what we need for the default build. This is more of a push towards using existing infra because those pieces are already looked after for other purposes. > - A script build_release_container.sh which automatically detects which ubuntu > version a given release should be buildable on (based on date). It works > great, and the heuristic works for all our versions. > - a script generate_release_links.sh which creates wrapper scripts > automatically > using prebuilt images (hosted on my dockerhub). > It would be nice if these two could take any hash, instead of just a tag. This is one of the things that will depend on what you intend to achieve with this series. > TLDR: > $ ./scripts/build_release_container.sh v1.6.1 > $ podman run -it --rm qemu/v1.6.1 qemu-system-arm --version > > $ ./script/generate_release_links.sh qemu-time-machine > $ ./qemu-time-machine/v1.6.1/qemu-system-arm --version > QEMU emulator version 1.6.1, Copyright (c) 2003-2008 Fabrice Bellard > $ ./qemu-time-machine/v11.0.0/qemu-system-arm --version > QEMU emulator version 11.0.0 (v11.0.0) > Copyright (c) 2003-2026 Fabrice Bellard and the QEMU Project developers > > v3 > -- > > - extend dockerfile to support ubuntu 12.04, and lower older revision we can > build from v1.6.1 to v0.12.0. > > v2 > -- > > - fix generate_release_links.sh: was missing userns option for podman > - dockerfile: cleanup "|| true" and replaced with proper ifs > > Pierrick Bouvier (3): > tests/docker/dockerfiles: add release.docker > scripts: add build_release_container.sh > scripts: add generate_release_wrappers.sh > > scripts/build_release_container.sh | 62 ++++++++++++++++++++ > scripts/generate_release_wrappers.sh | 71 +++++++++++++++++++++++ > tests/docker/dockerfiles/release.docker | 76 +++++++++++++++++++++++++ > 3 files changed, 209 insertions(+) > create mode 100755 scripts/build_release_container.sh > create mode 100755 scripts/generate_release_wrappers.sh > create mode 100644 tests/docker/dockerfiles/release.docker
