-
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
Name prefix for OpenStackMachine related resources #2039
Comments
I knew sometimes we use tag, some times use description |
Yes tags can help to identify resources, but they do not help with compliance requirements for hostnames and resource names |
For the record I'm actively advocating for an alternate solution here: kubernetes-sigs/cluster-api#10463 |
/kind feature
Describe the solution you'd like
To address these user stories I propose a new field for the OpenStackMachine (and consequently for the OpenStackMachineTemplate):
.spec.namePrefix
. It would be used as a prefix for all OpenStack resources created by CAPO for this OpenStackMachine.The field would be optional. If not specified, the current behavior would remain, where resources gets their name based on the OpenStackMachine name.
Why not just name the OpenStackMachine differently?
Why not address this at the CAPI level?
Anything else you would like to add:
This feature is something that we didn't notice that we needed until the breaking change in CAPI v1.7.0. We had gotten used to the old (and admittedly confusing) behavior where infra machines were named by the infra templates. CAPO (and probably other providers as well) named the resources according to the infra machine and it was then very easy to change the names by switching infra template. Now we are stuck with fixed names based on the KCP and MDs, which cannot be changed. For new clusters, we can of course set the proper names where it matters, but that doesn't address the core issue here: we need control over the naming of the resources. With this feature request, I'm trying to address that so that we can have explicit control over it.
The text was updated successfully, but these errors were encountered: