cluster-api-provider-vsphere icon indicating copy to clipboard operation
cluster-api-provider-vsphere copied to clipboard

deploy CPI in same minor version as Kubernetes

Open yastij opened this issue 4 years ago • 6 comments

/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):

yastij avatar Feb 01 '21 18:02 yastij

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.go already has a variable KUBERNETES_VERSION which is used to input the k8s version. We could use something similar for the CPI version, with a reasonable default.

/assign

srm09 avatar Feb 01 '21 19:02 srm09

@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?

srm09 avatar Feb 01 '21 22:02 srm09

cc @fabriziopandini ptal when you can for templating ideas and if/how we can leverage clusterctl

yastij avatar Feb 02 '21 19:02 yastij

@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?

fabriziopandini avatar Feb 04 '21 14:02 fabriziopandini

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

fejta-bot avatar May 05 '21 14:05 fejta-bot

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),.

srm09 avatar Jan 30 '22 22:01 srm09

This is all gone now

/close

randomvariable avatar Aug 03 '23 18:08 randomvariable

@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.

k8s-ci-robot avatar Aug 03 '23 18:08 k8s-ci-robot