Feat/k8s update 20260528

[garloff]

OK, here's my thoughts on maintaining several series of minor k8s versions in parallel:

1. I have created the branches maint/scs2-1-33 and maint/scs2-1-34 (and I will do maint/scs2-1-35 as well). I will push to these from PRs and would enable branch protection for them as well. The changes to them for a new patch release would be minor ...
2. Some files contain a list of several minor k8s versions. This is at least versions.yaml and kubernetes.yaml. These I would keep in the main branch, as they can be the same across all branches.

Creating a set of new k8s release now comprises:
(a) Patching the common files and merging to main. This is what this PR is about.
(b) Patching each of the active maint/scs2-1-xx branches. (I will create PRs for these as well.) Note that the branch from (a) can be merged into these as well, so we are not stalling the dev process and still avoiding merge conflicts, as we reference the same commits this way.

If there is a cleaner way to structure this, let me know. Good topic for the container call ...

[garloff]

Sidenote: v1.33.12 should be there, but the image is missing, see issue osism/k8s-capi-images/326.

[janiskemper]

originally, we have had two options. First, the one you propose right now. Second, to keep it in one branch and to have different folders.

We decided for the latter one.

Because no-one used these cluster stacks in this repo in production, some utility functions were created that essentially made the pattern obsolete to have different folders.

I would therefore check whether we actually want to take that route to use different branches now. I'm not sure about the implications.

In general, I do think that bringing back any pattern to maintain the versions independently is a good idea.

Internally at Syself we used different folders until now.

[garloff]

Hmm, no strong opinion here. I think different branches is a bit more efficient, as git then knows that the files have a common origin ... but these are tiny text files that a diff -uNrp will nicely compare as well, so that point is not strong at all. I do think we need to establish a way of doing it, which we have not thus far: No subdirectories per maintained branch do currently exist ...
And then document it and follow through. (And no, there won't be much production use unless we treat this like production software with predictable updates etc.)
Let's tackle it in the container call tomorrow.

[garloff]

Side-discussion: Ideally we also merge #263, so the thing works for the production clusters I run as well.
(nSC does have storage AZs aligned with compute AZs and no cross-attach capability -- not such an uncommon pattern.)