Add namingStrategy for InfrastructureCluster

[simonostendorf]

What would you like to be added (User Story)?

As a cluster administrator I want to control how my InfrastructureClusters are named so that they match my other cluster-api components.

Detailed Description

When using cluster-classes the user can change the naming scheme of the resulting control-plane and the machine-deployment / machine-pool objects but not for the infrastructure cluster.

I think it would be nice to support a namingStrategy for infrastructure as well. This would allow me to remove the random id at the end because my cluster names are already random ids.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature

/area cluster-class

[k8s-ci-robot]

@simonostendorf: The label(s) area/cluster-class cannot be applied, because the repository doesn't have them.

In response to this:

What would you like to be added (User Story)?

As a cluster administrator I want to control how my InfrastructureClusters are named so that they match my other cluster-api components.

Detailed Description

When using cluster-classes the user can change the naming scheme of the resulting control-plane and the machine-deployment / machine-pool objects but not for the infrastructure cluster.

I think it would be nice to support a namingStrategy for infrastructure as well. This would allow me to remove the random id at the end because my cluster names are already random ids.

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature

/area cluster-class

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[simonostendorf]

/area clusterclass

[chrischdi]

/triage accepted
/priority backlog

Feel free to take a look, assign and open a PR for this :-)

[chrischdi]

/help

[k8s-ci-robot]

@chrischdi:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[arshadd-b]

/assign

[arshadd-b]

Hi @simonostendorf I am interested to work on this. Could you please provide more information, it will be really helpful
Thanks

[simonostendorf]

Hi @simonostendorf I am interested to work on this. Could you please provide more information, it will be really helpful
Thanks

Nice, thank you!

Currently it's only supported to define a naming scheme for the ControlPlane hosts. The Infra Cluster gets a name with cluster name and a random string. I think it is useful to allow a naming scheme for this, so that the cluster can be named like the cluster name without the random string or something like that.

Do you understand what I mean?

[arshadd-b]

Did you mean something similar like we already we have ?
https://github.com/kubernetes-sigs/cluster-api/blob/main/internal/topology/names/names.go#L70

[simonostendorf]

I would like to see an option that the Infra Cluster gets the same name as the Cluster object when using Topology feature. I haven't thought about the implementation yet.

I was thinking about something like the namingStrategy that exists for machines, see https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api/controlplane.cluster.x-k8s.io/KubeadmControlPlaneTemplate/v1beta1@v1.9.4#spec-template-spec-machineNamingStrategy

[arshadd-b]

Hi @chrischdi
I had gone through the code for existing components naming strategy and also checked this PR for namingstrategy #9340
I think we need to have something like InfracstructureClass here https://github.com/kubernetes-sigs/cluster-api/blob/main/api/v1beta1/clusterclass_types.go#L90C17-L90C36
like we have for controlplane https://github.com/kubernetes-sigs/cluster-api/blob/main/api/v1beta1/clusterclass_types.go#L95
This will involve api level changes
Is this what expected ?
Thanks

[simonostendorf]

Hi @chrischdi I had gone through the code for existing components naming strategy and also checked this PR for namingstrategy #9340 I think we need to have something like InfracstructureClass here https://github.com/kubernetes-sigs/cluster-api/blob/main/api/v1beta1/clusterclass_types.go#L90C17-L90C36 like we have for controlplane https://github.com/kubernetes-sigs/cluster-api/blob/main/api/v1beta1/clusterclass_types.go#L95 This will involve api level changes Is this what expected ? Thanks

I think this is what I mean.

[sbueringer]

I think we need to have something like InfracstructureClass here

Hm good point.

@fabriziopandini @chrischdi What do you think about adding infrastructureNamingStrategy for now on the same level as infrastructure and then with v1beta2 we can move both fields into a InfrastructureClass struct & field? (then we also have the flexibility to add more fields going forward like Metadata).

Additional context. In YAML this would look like this:

  controlPlane:
    ref:
      apiVersion: controlplane.cluster.x-k8s.io/v1beta1
      kind: KubeadmControlPlaneTemplate
      name: quick-start-control-plane
      namespace: default
    namingStrategy:
  infrastructure:
    ref:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: DockerClusterTemplate
      name: quick-start-my-cluster
      namespace: default
    namingStrategy: # < in v1beta2
  infrastructureNamingStrategy: # < in v1beta1

(@simonostendorf @arshadd-b we can't simply change the type of ClusterClassSpec.Infrastructure to InfrastructureClass within v1beta1 as that would be a breaking change on the Go type level)

[fabriziopandini]

Adding something non breaking in v1beta1 and refactoring the API in v1beta2 makes sense for me

[arshadd-b]

Thanks @sbueringer @fabriziopandini , I will start working on implementation

[sbueringer]

Follow-up for v1beta2 is tracked via #10852