clusterclass control-plane namingStrategy is not applied for Azure cluster

[arno-pons]

What steps did you take and what happened?

Deploying an Azure cluster using a clusterclass with a spec.controlPlane.namingStrategy.template attribute with value: "{{ .cluster.name }}-control-plane-{{ .random }}"

doesn't create capz objects name (azuremachinetemplate, azuremachine and azure VM) matching this strategy. Only capi objects (kubeadmcontrolplane and machine) are correctly named. capz objects seems to be named with default strategy: "{{ .cluster.name }}-{{ .random }}"

Here the clusterclass configuration:

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  name: my-cc
  namespace: default
spec:
  controlPlane:
    ref:
      apiVersion: controlplane.cluster.x-k8s.io/v1beta1
      kind: KubeadmControlPlaneTemplate
      name: my-kcpt
      namespace: default
    namingStrategy:
      template: "{{ .cluster.name }}-control-plane-{{ .random }}"
[...]

What did you expect to happen?

Names of control-plane VM and nodes should match clusterclass namingStrategy.

Cluster API version

• capi version: 1.6.1
• capz version: 1.13.0

Kubernetes version

• kubernetes version: v1.28.5

Anything else you would like to add?

clusterclass with same namingStrategy for another infrastructure provider (vSphere capv) results in VM and node names matching the naming strategy.

Same issue has been opened on capz provider side: https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/4597

Label(s) to be applied

/kind bug One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.

[chrischdi]

• 9340

introduced the naming strategy, which applies to the objects and made it into CAPI v1.5.x (cherry-pick) and v1.6:

• ControlPlane
• MachineDeployments
• MachinePools

Part of it was not to apply the same naming also for the objects created by the above objects.

The following issue/PR:

• 9733

• 9833

introduced a change to re-use the naming from the upper objects to the objects they create and made it into v1.7.0.

Today we generate separate random names for Machine / InfraMachine / BootstrapConfig in KCP and the MachineSet controller. This makes it unnecessarily complicated to correlate these objects as an operator.

The idea is that we should only create one random name on Machine create and then use it for all 3 objects

So beginning with v1.7.0 you should have your expected behaviour.

[arno-pons]

Hi @chrischdi,

Thanks for your feedback.

[chrischdi]

So I guess we can close this @arno-pons ? :-)

[arno-pons]

Yes of course.

We will try with v1.7.0 version ASAP and let you know if we still have issue 😄.

Thanks.

[chrischdi]

@arno-pons friendly reminder: do you have any results to share :-)