-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Shorter machineset names #8585
Comments
I think in But I think this doesn't necessarily mean that we need both in the MachineSet name. As far as I know the MachineSet name is now independent of the So I wonder if we can do this: name = computeNewMachineSetName(deployment.Name+"-", apirand.String(5)) instead of name = computeNewMachineSetName(deployment.Name+"-", apirand.SafeEncodeString(uniqueIdentifierLabelValue)) I don't see the benefit of including the uniqueIdentifierLabelValue in its encoded form in the MachineSet name (or I just forgot why it was important) |
Looking into this a bit closer. I think our goal was to limit MachineSet names to max 63 characters. But I think we don't achieve this with our current code cluster-api/internal/controllers/machinedeployment/machinedeployment_sync.go Lines 369 to 374 in d8dae54
This ensures base (which is (This would be also solved by passing in |
An example (obfustacted but representative of length) machine name in our environment... foo-wl-01-zookeeper-zk9v9-7c45bf7958xqccjd-b2w96 with our environment DNS domain appended, the node name would be foo-wl-01-zookeeper-zk9v9-7c45bf7958xqccjd-b2w96.foo.bar.blah.io This is one character too long and it will not be able to join the cluster. |
We created the Then we included the additional apirand(5) here to avoid name clashing during rolloutAfter operations Should we let |
/triage accepted |
I think we should just use I don't see any reason to include uniqueIdentifierLabelValue in the MachineSet name (after appending the random string to the template hash + encoding it's unrecognizable anyway) Example: https://storage.googleapis.com/kubernetes-jenkins/logs/periodic-cluster-api-e2e-main/1653315829829210112/artifacts/clusters/bootstrap/resources/clusterclass-rollout-pdvhn2/MachineSet/clusterclass-rollout-i2j56w-md-0-fv4xl-66b8656df6x8g89s.yaml |
IIRC, we originally included the template hash (encoded) in the name to match what was done before in-place propagation. Historical reasons for doing this was to handle cache miss and deal with cases where the controller mistakenly tries to re-create a duplicate MS. But now that we have polling and the random suffix in the names all of this no longer applies. It should be safe to drop the hash from the name as long as we keep the random suffix. This, as @sbueringer mentioned, should also fix bug that MS names should be <= 63 characters in the current code. Also, the |
Let me tackle this :-) /assign |
What would you like to be added (User Story)?
Since 1.4.0, machineset names have been longer due to the inclusion of an additional random string after the template hash.
This ultimately gets included in the cluster's node names, which can present a problem. Node names can only be up to 63 characters at this time.
Particularly for users who have multiple machineDeployments with descriptive names, or are using FQDNs for their node names, every character counts. The longer machineset names can make the difference between viable or unviable node names and cause users to have to rename their machineDeployments to less descriptive names.
Detailed Description
https://github.com/kubernetes-sigs/cluster-api/blame/main/internal/controllers/machinedeployment/machinedeployment_sync.go#L240
https://kubernetes.slack.com/archives/C8TSNPY4T/p1682698175472899
Anything else you would like to add?
Might it be viable to use just the random string for the uniqueIdentifierLabelValue and drop the hash portion?
Label(s) to be applied
/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.
The text was updated successfully, but these errors were encountered: