You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a security/network operator, I want CAPO resources to be easily identifiable by their name and hostname, so that I can keep track of and verify security policies between environments.
As a cluster admin, I want control over how CAPO resources are named, so that they can fit in with external resources living in the same OpenStack project.
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?
It is created and named by CAPI, so we do not have direct control over it.
It is just implicit that we name the resources after it, so it cannot really be relied upon (unless we make it explicit).
The OpenStackMachine gets its name from the MachineDeployment or (Kubeadm)ControlPlane. These must be replaced in order to change the naming scheme (and it is anyway not part of the contract). For the KCP that means recreating the cluster.
Why not address this at the CAPI level?
There is no contract that binds CAPO to name the resources in a certain way, so it does not help to get control over the naming of the OpenStackMachine from CAPI.
There is an issue (Add guidance on infrastructure resource names to provider implementation guides cluster-api#7030) that may address this. However, making it part of the contract will affect all implementers and probably be very hard to get consensus on. Not to mention that each provider has their own limitations and rules from their infrastructure that may affect what is possible to do.
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:
.spec.namePrefix. It would be used as a prefix for all OpenStack resources created by CAPO for this OpenStackMachine.
I knew sometimes we use tag, some times use description
not sure which one is better but I think it worthy a discussion to dintinguish resource belong to different cluster?
/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: