Testing upgrades

[cgwalters]

A question came up on a chat forum which is basically: what's the best way to test upgrades for systems that should follow a "floating" tag? Let's say I am shipping quay.io/exampleos/exampleos:latest as a floating tag, but there are also :1.1 and :1.2 explicit tags for example.

Before :latest points to :1.2, when we use e.g. Anaconda or bootc install, the system will be at :1.1. But when we point :latest at :1.2, then newly generated installs will point directly at it.

First of course, a lot of testing can be done via bootc switch, so we could use that to go to the :1.1 tag and then back.

But for some workflows it's a bit more ideal if the system starts from what is effectively :1.1 but we want bootc upgrade to go to :1.2. In order to do that, we can make use of the "target image reference" functionality, something like this: podman run --privileged ... quay.io/exampleos/exampleos:1.1 bootc install to-filesystem --target-imgref quay.io/exampleos/exampleos:latest ....

In this invocation we'll be using the :1.1 image to do an install, but the system will be configured to track :latest.

Unfortunately today, Anaconda doesn't directly expose this, but it's possible to do via %post, like this code is doing: https://github.com/osbuild/images/blob/f667cdfbaaaa8b2d5e579f9f0294b24c7b680028/pkg/manifest/anaconda_installer_iso_tree.go#L530

osbuild/bootc-image-builder#559 tracks the feature request for bootc-image-builder to do this.

[vrothberg]

I am just writing a blog on tags at the moment :^)

My general thought is that there is no single way to handle version upgrades in those cases as tags have different meaning/semantics for different images. So I would not like bootc upgrade to do some magic and change the image reference from 1.1 to 1.2.

A bootc switch would be my recommendation at the moment. If users want to have the minor-version upgrade scenario you describe above, then they should really use the exampleos:1 tag.

[vrothberg]

The scenario is very very similar to podman auto-update where updates are pinned to a specific tag. So there is some kind of contract between the image builder and the consumer where both sides understand the update policy and support cycle of a given image:tag. An image can be "updated" when the digest changes - for the specific image:tag.

So if a user starts with image:1.2.3 and expects updates to float in, they are mistaken. I feel quite strongly that this is something we need to document and provide strong best practices for.

Using the tag

• X.Y.Z means that only this specific version will be used
• X.Y means that the major-minor pair (X.Y) will be used and patches (Z) will be applied
• X means that the major version (X) will be used and both minor-version updates (Y) and patches (Z) will be consumed

[cgwalters]

So I would not like bootc upgrade to do some magic and change the image reference from 1.1 to 1.2.

100% agreed! This discussion is about having bootc upgrade not change the image reference, but in testing an upgrade from an older container image to a newer one, while still having the workflow be bootc upgrade.

For people who are making disk images from containers, they implicitly always have that starting point snapshot.

This is about helping people who don't do that (for good reasons as maintaining lots of disk images starts to stink).