Feature: Specify node names at cluster creation

[torsina]

Tangent/followup to issue #85 and PR #107

Motivation

I was looking to set up a file with a list of possible node names that Claudie could choose from while giving a name to every node.

Description

Adding a field in the InputManifest, either as a path to a file containing unique node names, or add a list property in the InputManifest with the wanted node names. Those names would be taken from the list either at random or in ascending/descending order depending on a second field mentioning which policy should be used to pick said names.

There would be one of those set of fields for every pool of node (control plane and master, for every provider). To keep in line with the issue and PR mentioned at the top the node names might still need a hash at the end of their name to guarantee uniqueness (ex: {NODE_NAME}-{HASH}).

This would make it easier in case you want certain pods only on nodes with specific meaning, and can't remember which hash does what, without having to rely on different node pools. Or in the case of a selfhosting situation and wanting a naming scheme both on your cluster and nodes.

This alongside with my other feature request #1299 would massively expand the flexibility of Claudie and wouldn't require other tools post-cluster creation to do what is needed to achieve those goals.

Exit criteria

• Check for feasability/if something prevents this from being possible
• Create PR
• Add the list fields in the InputManifest struct and the field for the order in which to use said names
• Implement the change in the go code
• Test real life scenarios with each provider to check for unseen conflicts
• Merge PR

[MiroslavRepka]

I would assume that controlling where pods are scheduled would be either by labels or taints. Please see how you can use those here and here. IMO that is more flexible than using node names.

IIRC, both should be supported by Claudie already.

Hope this helps.

[torsina]

I am less concerned of where pods are scheduled (I already know how to do that with taints/labels). I was only asking for node names

[torsina]

If this isn't supported in Either Claudie or Kind my only solution is to create my own ansible playbook with setting up each node first with the --node-name / --hostname-override for kubelet and kubeadm

To some extent this is pretty dissapointing since this seem like a pretty light PR change, I just do not know enough of go compared to other languages to make the PR to support this myself (if this PR would only be considered and I wouldn't have to make a fork because maintainers would refuse this addition)

[MiroslavRepka]

Well, I was trying to understand the use case of such a feature and the only context for this given was pod scheduling. I am not saying this will not be supported, I am just saying that I, personally, do not see the value of it. However take it with a pinch of salt, as I am no longer an active contributor :)

[torsina]

It wouldn't be for commercial purposes but for a self-hosted setup, the same way you name your different boxes with a naming scheme, I want to name my nodes with a naming scheme

[torsina]

and it could clarrify which node oes what if I make certain deployment only schedulable on specific nodes for one reason or another

[bernardhalas]

Hi @torsina , I'd like to break this down as there are several aspects to this feature request:

• Nodes are cattle, not pets; this means that I would not worry much about node names, but rather about their labels or taints
• If you need to pin your workload to a particular node, nothing prevents you from doing a nodepool of size 1 and labelling it accordingly; if you need to do this for a large number of nodes, I'd question the need for the Kubernetes as your orchestrator
• The reason why somebody might want to go with this, I can imagine, is a company-wide policy for naming nodes, for various reasons; but I don't see this reason being strong enough to justify the increased complexity in the InputManifest to support this

That being said, is there an argument we are overlooking here?