deploy CPI in same minor version as Kubernetes
/kind feature
Describe the solution you'd like
As CPI runs some of k/k controllers, we need to match the CPI image tag with the KUBERNETES_VERSION. the patch version might be different between the tag and the kubernetes version though. we can have the CPI patch version as a const in packaging/flavorgen and use it.
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
- Cluster-api-provider-vsphere version:
- Kubernetes version: (use
kubectl version): - OS (e.g. from
/etc/os-release):
Info dump:
- vSphere CPI images are published at https://console.cloud.google.com/gcr/images/cloud-provider-vsphere/GLOBAL/cpi/release/manager?gcrImageListsize=30
- The idea is to keep the minor kubernetes and vSphere CPI versions to be the same.
generators.goalready has a variableKUBERNETES_VERSIONwhich is used to input the k8s version. We could use something similar for the CPI version, with a reasonable default.
/assign
@yastij Are we expecting the generated YAML to have this:
controllerImage: gcr.io/cloud-provider-vsphere/cpi/release/manager:'${KUBERNETES_VERSION}' and some bash magic to replace the k8s patch version with the CPI patch version?
cc @fabriziopandini ptal when you can for templating ideas and if/how we can leverage clusterctl
@yastij this is a tricky request. If we encode the function that maps kubernetes version and cpi version in CAPV, that won't be accessible in clusterctl while processing the templates. Also I see a potential problem for upgrades, because CRS currently only support applyOnce, and AFAIK at least in CAPI there is nothing that will take care of upgrading CPI Least but not last, what is the expected behaviour/the supported version skew while a cluster is updating and there are more Kubernetes versions coexisting at the same time?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
We could request the vSphere Cloud Provider folks to publish the CPI image for every patch version (since currently the images are published for each of the minor version upgrades but not for every patch, could be coz there might be no changes to the CPI corresponding to every particular patch version of k/k)
That way we can use the same version number, KUBERNETES_VERSION variable that is used in the existing templates (read the version used in MD, KCP),.
This is all gone now
/close
@randomvariable: Closing this issue.
In response to this:
This is all gone now
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.