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

clusterclass control-plane namingStrategy is not applied #4597

Open
arno-pons opened this issue Feb 26, 2024 · 4 comments
Open

clusterclass control-plane namingStrategy is not applied #4597

arno-pons opened this issue Feb 26, 2024 · 4 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@arno-pons
Copy link

/kind bug

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.

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.

Environment:

  • capi version: 1.6.1
  • capz version: 1.13.0
  • kubernetes version: v1.28.5
@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Feb 26, 2024
@mboersma mboersma added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Mar 28, 2024
@willie-yao
Copy link
Contributor

willie-yao commented Apr 19, 2024

Hi @arno-pons! Adding the namingStrategy field to the controlPlane spec only applies the strategy to the controlplane resources such as kubeadmcontrolplane. You can specify namingStrategy for your machineDeployments or machinePools workers and the names of the Azure resources should match the namingStrategy.

I just verified this by adding namingStrategy like so:

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  name: my-cc
  namespace: default
spec:
  workers:
    machineDeployments:
    - class: ${CLUSTER_NAME}-worker
      namingStrategy:
        template: "{{ .cluster.name }}-foo-{{ .random }}"

kubectl get azuremachine shows the following:

NAME                                             READY   SEVERITY   REASON                    STATE   AGE
willie-clusterclass-9406-foo-44xp6-8rn9x         False   Info       Creating                          70s
willie-clusterclass-9406-foo-rb6ps-rpr7f-pj6zt   False   Info       WaitingForBootstrapData           4m33s
willie-clusterclass-9406-foo-rb6ps-rpr7f-xrjnn   False   Info       WaitingForBootstrapData           4m33s

Let me know if this works for you!

@arno-pons
Copy link
Author

arno-pons commented Apr 22, 2024

Hi @willie-yao,

Thanks for you feedback.

My issue is related to the name of control plane azuremachine, not worker ones.
For the worker, we are agree that the namingStrategy at machineDeployments level is working well.

But for controle plane nodes, the only field available for naming strategy, from my understanding, is the spec.controlPlane.namingStrategy.template. And as you say, it seems to apply at kubeadmcontrolplane object level only.

Any idea how to set naming strategy for control plane azure machines/VMs ?

@thefirstofthe300
Copy link

I think this might be a CAPI core bug. I just hit this exact same behavior despite using the AWS provider instead.

@willie-yao
Copy link
Contributor

@thefirstofthe300 Thanks so much for the info! I have been trying to see why this isn't working in CAPZ since they mentioned this working for the VSphere provider. All logic that involves namingStrategy happens in CAPI so it is probably a CAPI issue. @arno-pons would you be able to create an issue in CAPI for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
Status: No status
Development

No branches or pull requests

5 participants