Open mxmxchere opened 7 months ago
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.
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 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:
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