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 for Azure cluster #10754

Closed
arno-pons opened this issue Jun 14, 2024 · 8 comments
Closed
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@arno-pons
Copy link

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:
kubernetes-sigs/cluster-api-provider-azure#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 k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. labels Jun 14, 2024
@k8s-ci-robot
Copy link
Contributor

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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jun 14, 2024
@chrischdi
Copy link
Member

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:

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
Copy link
Author

Hi @chrischdi,

Thanks for your feedback.

@chrischdi
Copy link
Member

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

@arno-pons
Copy link
Author

Yes of course.

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

Thanks.

@chrischdi
Copy link
Member

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

@fabriziopandini
Copy link
Member

/close
we can eventually re-open if there are feedback

@k8s-ci-robot
Copy link
Contributor

@fabriziopandini: Closing this issue.

In response to this:

/close
we can eventually re-open if there are feedback

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.

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. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

4 participants