Supported k8s versions

[garloff]

As an SCS cluster user, I want to be sure to have a consistent minimal set of k8s versions available across all SCS-compliant KaaS offerings.
(As SCS KaaS operator, I want to understand what k8s versions I need to offer to comply.)

Definition of Ready:

• User Story is small enough to be finished within one sprint
• User Story is clear and understood by the whole team
• Acceptance criteria are defined
• Acceptance criteria are clear and understood by the whole team

Definition of Done:

• All acceptance criteria are met
• Changes have been reviewed
• CI tests have run successfully
• Documentation has been updated
• Release Notes have been updated

[berendt]

After definition it has to be implemented/integrated in https://github.com/osism/openstack-image-manager/blob/main/etc/images/kubernetes.yml and https://github.com/osism/k8s-capi-images/blob/main/src/update-extra-vars.py.

[garloff]

Decision from 2022-11-28 discussion:

• Must provide latest minor version (minor acc. to semver style) no later than 4 mon after release
• Must provide latest patch version no later than a week after release
  • Should be faster for critical CVEs (CVSS >= 8)
  • Should be tested

[garloff]

TODO: Write ADR

[garloff]

Open question: Should we recommend a "beta" channel, where newer minor versions or newer patch versions can be made available prior to them being fully qualified?
Application operations teams may want to understand what changes they need to perform and start testing before the official availability of the latest k8s version. (Of course final qualification will need to be done after the operator provides the latest version with official support.)

[garloff]

Does not need to standardized:

• Providers can still do it
• Cutting edge customers might tend to deploy capi themselves and thus don't depend on a standardized way to get early access ...