-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📖 Proposal for microversion support #1565
📖 Proposal for microversion support #1565
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lentzi90 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
36cea4d
to
395d4e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this, this is exactly how I believe microversions should be consumed.
### Implementation details and notes | ||
|
||
There is already one part of CAPO that actually has dynamic versioning, thanks to Gophercloud. | ||
The [authentication](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/904381c7f31f8fdda83586f208339cd2aab53e78/pkg/scope/provider.go#L173) flow makes use of [this function](https://github.com/gophercloud/gophercloud/blob/6e1423b668969548d46fd862202a3bf9623b52e0/openstack/client.go#L92-L112) that chooses the version from a list of supported versions, provided by the caller, and the range of versions supported by the server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not really a microversion. I get the point, but this example is super simple. I believe this is a better one: https://github.com/kubernetes/cloud-provider-openstack/blob/35ce5a0c59da23795fc48b292e3736f8cb0bb10f/pkg/util/openstack/loadbalancer.go#L101-L162
Please note this is not really a microversion either, Octavia does regular API versioning and you cannot request an older microversion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I added the linked example but I also kept the original since I think it can still be useful for the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting the effort into microversion handling.
The `clouds.yaml` configuration file already has support for specifying the version so this should be familiar to many users. | ||
However, Gophercloud does not support reading all the versions from this file as of now. | ||
The main reason for avoiding this alternative, though, is the lack of control that CAPO has. | ||
With a well defined list of supported and tested versions, perhaps it could still be considered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A well defined list of supported and tested versions would be nice.
Howerver, I don't think it should be expected that our list is a complete list of all available microversions of OpenStack Cinder, Manila, Barbican, Nova and wether we tested or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very true. I'm mainly keeping this here as a reminder of where the discussion started. That is, I wanted to let the user pick the version (with all the consequences that it brings). So if we created a list of known good versions for CAPO (the list could have a single version even) then maybe we could still consider this implementation. The user could check that the version they set is supported, but in theory they could then still set an unsupported version (with the risks that it would bring).
This adds a proposal for how CAPO could support more than one microversion. The current situation is that we hard code a microversion that is then used for all API calls. This is currently done for Nova. Other clients are not configured with a version as of now.
395d4e7
to
a6938bf
Compare
I like this as a problem statement. However, to merge it I think we'd want a discussion of the proposed implementation. There was one at some point. Do you want to add it to the doc? |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
I knew you'd previously created a design doc repo! Lets merge this and I'll update mine to correspond. /lgtm |
Thanks! |
What this PR does / why we need it:
This is a proposal related to #1448 for how to support more microversions in CAPO.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):This is just a proposal so it won't contain the actual implementation.
Special notes for your reviewer:
TODOs:
/hold