Skip to content
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

Open
lentzi90 opened this issue Apr 26, 2024 · 3 comments · May be fixed by #2035
Open

Name prefix for OpenStackMachine related resources #2039

lentzi90 opened this issue Apr 26, 2024 · 3 comments · May be fixed by #2035
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@lentzi90
Copy link
Contributor

/kind feature

Describe the solution you'd like

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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 26, 2024
@lentzi90 lentzi90 linked a pull request Apr 26, 2024 that will close this issue
3 tasks
@jichenjc
Copy link
Contributor

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

@lentzi90
Copy link
Contributor Author

Yes tags can help to identify resources, but they do not help with compliance requirements for hostnames and resource names

@mdbooth
Copy link
Contributor

mdbooth commented Apr 30, 2024

For the record I'm actively advocating for an alternate solution here: kubernetes-sigs/cluster-api#10463

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
Status: Inbox
Development

Successfully merging a pull request may close this issue.

4 participants