MAINT: Remove date from image name

[khalford]

Removing the date from the image name. If we follow the same naming as our OS images then we can release patches to the images without making the user manually update their clusters. New nodes and replaced nodes will pick up the new image without needing to change the user-values.yaml

[anish-mudaraddi]

does this actually work? Have you tested CAPI is able to pick up new images with the same name automatically?

[anish-mudaraddi]

personally I think we shouldn't change images underneath users - could lead to issues - much prefer to state that they need to upgrade themselves

[khalford]

personally I think we shouldn't change images underneath users - could lead to issues - much prefer to state that they need to upgrade themselves

@anish-mudaraddi I don't agree. For example a user is on image v1.33.2. A CVE is released and then a patch is released so we build image v1.33.3. We would then have to tell users to move from v1.33.2->v1.33.3. Which at that point they might as well just move to v1.34 since they are doing an upgrade anyway. Whereas if we drop the date and patch from the image then they can just tell the cluster to rebuild all the nodes and the latest patch will be picked up

[anish-mudaraddi]

I see your point - @DavidFair is this what we want to do?

[DavidFair]

we shouldn't change images underneath users - could lead to issues

Agreed, if the UUID changes where an image gets re-released by accident or chance (no patch between a critical CVE fix) and CAPI/CAPO notices it will rebuild nodes (safely), but not at a "good time" for users. If you're mid-way through a 2 day course or 1 day-long auto-reduction job you're not doing to be very happy....

I can see the merit in simplifying this to how our Ubuntu and RL images are named though. Thinking about this the cases we have are:

• Names with the version that has changed -> Users have to opt-in to upgrade
• Names with the same version (accident or just bad timing for a CVE) -> Need to guard against it causing problems. We could simply append something like -rev2 then chase people using the old image with our ST2 action and security policy

If people don't like the idea of having a -rev2 where the versions match we could use the image UUID in our user-values.yaml, but I'm less keen on this as it's explicit but opaque

Also another problem I've just thought of using K8s versions is it's not clear which image is newer when an image is near it's from our side. E.g. is 1.32.3 or 1.33.1 newer if I need a patch to my OS. If I go into Horizon and my instances and see 1.34.5 does that mean my VMs have been patched in the last 2-3 months?
In that case it might be better to even go for capi-2026-01 so I can see in June "hey none of my VMs have been updated, better get on that"

Not sure what our thoughts are, I'm on the fence as there isn't a good clean option on this so far 🤔

---

This KEP and doc makes me think we could drop to a single image + binary emulating older versions that are "in the supported range" once we're past v1.32.

When we get everyone to 1.32+ and we test this could we could simply drop to a single image (or 2 while we get people off EOL ones) and potentially rejig our naming convention at the same time then? Our images could literally just be capi-ubuntu at that point....

AFAIK our helm templates set the K8s version from user-values.yaml so this would allow us to go to a single image akin to Ubuntu and RL without compatibility problems (plus the old image would still be there and could be referred to by UUID if we need to rollback)

[khalford]

we shouldn't change images underneath users - could lead to issues

Agreed, if the UUID changes where an image gets re-released by accident or chance (no patch between a critical CVE fix) and CAPI/CAPO notices it will rebuild nodes (safely), but not at a "good time" for users. If you're mid-way through a 2 day course or 1 day-long auto-reduction job you're not doing to be very happy....

I can see the merit in simplifying this to how our Ubuntu and RL images are named though. Thinking about this the cases we have are:

* Names with the version that has changed -> Users have to opt-in to upgrade

* Names with the same version (accident or just bad timing for a CVE) -> Need to guard against it causing problems. We could simply append something like `-rev2` then chase people using the old image with our ST2 action and security policy

If people don't like the idea of having a -rev2 where the versions match we could use the image UUID in our user-values.yaml, but I'm less keen on this as it's explicit but opaque

Also another problem I've just thought of using K8s versions is it's not clear which image is newer when an image is near it's from our side. E.g. is 1.32.3 or 1.33.1 newer if I need a patch to my OS. If I go into Horizon and my instances and see 1.34.5 does that mean my VMs have been patched in the last 2-3 months? In that case it might be better to even go for capi-2026-01 so I can see in June "hey none of my VMs have been updated, better get on that"

Not sure what our thoughts are, I'm on the fence as there isn't a good clean option on this so far 🤔

This KEP and doc makes me think we could drop to a single image + binary emulating older versions that are "in the supported range" once we're past v1.32.

When we get everyone to 1.32+ and we test this could we could simply drop to a single image (or 2 while we get people off EOL ones) and potentially rejig our naming convention at the same time then? Our images could literally just be capi-ubuntu at that point....

AFAIK our helm templates set the K8s version from user-values.yaml so this would allow us to go to a single image akin to Ubuntu and RL without compatibility problems (plus the old image would still be there and could be referred to by UUID if we need to rollback)

Okay so can we drop the date but leave the patch number?

[DavidFair]

Okay so can we drop the date but leave the patch number?

Just thinking about

it's not clear which image is newer when an image is near it's EOL from our side.

(Missed EOL on that)
If we maybe name the last K8s minor version we'll build something like 1.10.5-eol, it's obvious that I need to get off 1.10.x as there won't be another version
For every other release the user only has to look for 1.11.x != 1.11.y, or 1.11.x-rev2 to see there's a newer image
Anyone on 1.10.5-eol can clearly see there's no upgrade path in 1.10.x so they need to go to 1.11.y which solves the readability problems and is another incentive to get off an image that's literally tagged EOL

It means I'd be happy dropping the date, as a user can then easily tell if there's a newer image and when they're on a dead series

If you're happy with this as a plan (happy to discuss it more) could you put WTTE of "the oldest minor release that's EOL from K8s should have 'eol' appended manually by running 'openstack....'"

As I'm hoping to get 1.32+ and switch to a single unified image and point people to the K8s supported versions docs instead, so any tooling to do this automatically would be removed at that point too

[DavidFair]

LGTM, hopefully we simplify it down even further in the future 🤞