Closed gawertm closed 3 months ago
will discuss in the standup / refinement on thursday
@vxav will contact phoenix SA for CAPA and understand how they do it also with compatiblity of CPI version and Kubernetes versions
I suppose we can close this since there are ongoing discussions regarding CAPI release concept https://gigantic.slack.com/archives/C95NTB55M/p1692800035313419
ok with me. we just need to make sure then, that this topic gets included in the release discussion.
looping also in @erkanerol as the topic got already discussed in SIG architecture. do you know if this will be covered by the current state of the capi release concept?
K8s+Node versioning were discussed briefly but I don't think we have checked in detail. I am going to follow this issue.
BTW, original context is there 👉 https://gigantic.slack.com/archives/C01F7T2MNRL/p1685524091645229
cluster-azure has default k8s version values. I think we should follow the same method as we'll have hybrid clusters.
to be aligned with current turtles changes of cluster charts and cluster independent charts
This has been done a long time ago now 😄
Other (cloud) provider teams bake the k8s version in the cluster chart and upgrade the chart to upgrade the cluster. In their case the instance image is picked automatically based on the k8s version IIUC.
For onprem it's a bit different as we upload the VM images and they could be named wildly differently across customers.
If we wanted to follow the same pattern and bake versions in the charts we need to enforce VM template names to the customers (which I think is a good idea) and bake both
k8s version
andVM template name
inside the charts.At the moment we don't do that, in order to upgrade a cluster we change the values of the cluster app configmap.