-
Notifications
You must be signed in to change notification settings - Fork 253
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
✨ Add NamePrefix field to OpenStackMachine.Spec #2035
base: main
Are you sure you want to change the base?
✨ Add NamePrefix field to OpenStackMachine.Spec #2035
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found 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 configuration. |
Unfortunately I don't have time to go into this deeply today, but my first impression is that I'm not keen. It's worth noting that I'm generally supportive of the new CAPI default. It has always been a trip hazard that the Machine and InfraMachine have different names, and making them the same should be simpler for most people. However, as you point out in the CAPI issue, it has been this way long enough that I think it's reasonable to treat it like a breaking change in practise, regardless of whether it was documented. I hope we can work with the CAPI folks to sort that out. That said, this change would introduce that same trip hazard in CAPO, just moved one level down. The idea that cloud resources are named after the OpenStackMachine which owns them is simple and elegant. I'm not keen to break it, especially now that we've released v1beta1 and would be left supporting it indefinitely. My strong preference is to work with CAPI to enable backwards-compatibility for the inadvertent breakage. I took a brief look and the code to support the previous behaviour is still there. I think this can and should be implemented by adding a backwards-compatibility flag (optional, defaults to the new behaviour) to CAPI. |
Thank you for the comment @mdbooth ! I was reluctant to push this to begin with. Now I have a better understanding of the issue and the use-case. Based on that I have created #2039. Could you please take a look at the issue and see if this makes sense to you? I'm very open to suggestions for how exactly we should implement this! |
1b55b32
to
1782d5a
Compare
// NamePrefix is an optional string that will be used as a prefix for the name of OpenStack | ||
// resources created based on this OpenStackMachine. A random suffix will be added to the prefix. | ||
// If omitted, the name of the OpenStackMachine will be used as name. | ||
// +kubebuilder:validation:MaxLength:=255 |
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.
Can we do better here? Are there any specific requirements on names in OpenStack that we could include?
1782d5a
to
6b61809
Compare
This adds a new field to the spec of OpenStackMachines: `namePrefix`. It is an optional field that can be specified as a way to influence how OpenStack resources are named. If it is not specified, the OpenStackMachine name will be used (current behavior). Signed-off-by: Lennart Jern <[email protected]>
6b61809
to
8ce8116
Compare
It looks like you're making good progress in kubernetes-sigs/cluster-api#10511. I think this PR would be redundant if we're successful getting this fixed in CAPI. Can we hold fire on this to see how that goes? I'd very much prefer to see this fixed in CAPI rather than carry our own custom workaround. |
Sure, there is no hurry with this. However, kubernetes-sigs/cluster-api#10511 will only provide a temporary solution. It is targeting only the release branch and will be gone by CAPI v1.8 |
What this PR does / why we need it:
This adds a new field to the spec of OpenStackMachines:
namePrefix
. It is an optional field that can be specified as a way to influence how OpenStack resources are named. If it is not specified, the OpenStackMachine name will be used (current behavior).Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #2039, related to kubernetes-sigs/cluster-api#10463.
Special notes for your reviewer:
TODOs:
/hold