[Feature Request] Require up-to-date cluster-api images for OpenStack

[mxmxchere]

The problem that brings us here is how to update and keep track with upstream kubernetes versions when using the cluster-stacks approach on OpenStack. As the SCS K8S Version Policy formulates, SCS is quite eager to keep track with the upstream work and does not want to fall behind:

We want to achieve an up-to-date policy, meaning that providers should be mostly in sync with the upstream and don't fall behind the official Kubernetes releases.

We came up with two solutions that are described in today's container minutes

In short the two Options are:
A.) Mandate the CSP to keep cluster-api Images up-to-date, then the kaas-user can choose the kubernetes version by setting it in the cluster-resource.

B.) Use CSCTL to creates a new cluster-stack for each new kubernetes version, release it (automation is still needed here), change cluster-Stack-CRD (for each tenant) to reconcile the new clusterstack (creating a new clusterclass), let the CSPO upload the new image to OpenStack (for each tenant). Then the user can update the cluster resource (either the clusterclass, which in turn uses a new hardcoded image and/or the kubernetes version either automatically or via a webhook.)

If i understand scs-0104-v1-standard-images correctly we currently can not require a class of images:

If the status is mandatory, then at least one image MUST be present whose name matches the regular expression given via name_scheme.

We would need to change "at least one image" to "all images". Afterwards we could mandate the class of Cluster-API images to be updated.

Any thoughts / ideas / feedback appreciated @jschoone @garloff

[berendt]

For A: We provide up-to-date images here: https://github.com/osism/k8s-capi-images and also added a OSISM CLI command (osism manage image clusterapi) to have a way a CSP can provide the images in no time. Optional image definitions for the openstack-image-manager are also available.

[jschoone]

Hi @mbuechse, I put this on the agenda of the next SIG Standardization. Does it fit?