Towards user-defined workload cluster names everywhere

[marians]

We want workload cluster names to be chosen by the creator, not generated by the Giant Swarm backend. We also want to align our treatment of cluster names with other vendors we aim to import clusters from, e. g. EKS.

This includes the following changes:

• Allow for up to 63 character long names in UIs
  • This is scoped to UIs only. The actual length we can support is to be determined and may be shorter.
• Treat the cluster name as the main identifier in UIs (and phase out the tuple of cluster name and description)
• Prompt users to specify a cluster name on creation, allowing to fall back to a generated name
• Let admission controllers ensure uniqueness of a workload cluster name within a management cluster scope.

These changes should not affect users of the Vintage product (non-Cluster-API).

Why

• Short and cryptic cluster names like c3qp6 are hard to memorize and to communicate
• Some customers want to establish naming schemes and set the names themselves
• In GitOps, and in services like AWS EKS, the creator of a cluster must set the name

Background

Click here for the history of cluster names at Giant Swarm

In the beginning, our users could not influence the cluster names (called cluster ID back then) at all. They were generated on cluster creation by the backend. They were five characters long, and always had both letters and numbers in them. No other characters were allowed. In addition, users were allowed to set a user-friendly description (called the name back then). The rationale was: - Uniqueness of the cluster identifier would be guaranteed. Each new cluster would never re-use the identifier of a previously created (and possibly deleted) cluster. - The cluster identifier can never change, so users should not be tempted to think hard about a good name and to encode any information in it, which could be at some point. Instead, they should maintain the mutible description. When abandoning the Rest API and opening the management cluster's Kubernetes API (the Management API) as the interface for cluster management, and Cluster API resource types, creating a cluster became an interaction like any other resource creation: the user who creates the resource defines the name. In case of a cluster, the resource name (.metadata.name) is the identifier for the cluster. There was no longer a place for a generated identifier. However, in our user interfaces, where users created clusters imperatively, we still generated the identifier (name) for them to keep the system that we had introduced initially. However, clusters could be created in any way that kubernetes resources could be written. In addition to this, we added GitOps support and the cluster lifecycle for GitOps users no longer started in our UIs. Instead, it started in a declarative YAML file. Here, users wanted to use any names they could think of, even if they could never change it again in the future. With strict length restrictions in place (in the meantime we had relaxed the length limit from 5 to 10 characters), users started introducing elaborate naming schemes, where few letters and numbers expressed meaning like stage (dev vs. staging vs. prod), region, generation, etc. The latest influence on our handling of cluster names is the ability to import cluster created outside Giant Swarm, e. g. in EKS. Creators of these clusters are not limited in the way a Giant Swarm user is when naming a new cluster. So we found that we have to deal with yet another case of arbitrarily chosen names that would not fit into our stricter system. As a consequence, in November 2023 we have discussed in SIG UX at Giant Swarm to change the naming logic for clusters in user interfaces in the way that users are always asked to set a name for the cluster. In a graphical UI like the web UI there may be a generated name pre-filled to the input field, so that users don't have to think about a name when simply creating a test cluster. However, the principle changes to become compatible with the underlying API.

[marians]

Mockup for the cluster list in the web UI

We will no longer show the cluster name with an individual background color. We should still provide a copy-paste helper to copy the cluster name wherever it appears.

[gawertm]

@marians please see this issue also. there was a problem with an app that already had a too long name. apparently 53 is the limit for some ressources https://github.com/giantswarm/giantswarm/issues/28911

[weatherhog]

Helm is limited to 53 characters. Kubernetes is limited to 63 characters. Waiting for areas-kaas to make a decision to make a max length suggestion.

[AndiDog]

Related: https://github.com/giantswarm/roadmap/issues/2983

[weatherhog]

@marians are there any news on this one? It has been in Up next for the last 3 months without being taken care of?

[marians]

To me it seems that this story is blocked by our practice of generating names (e. g. for kubernetes resources) by concatenating cluster names with other names, like cluster and app name. This practice means that we cannot give a fixed number regarding the length limit of a cluster name.

Either we stop that practice.

Or we come up with a pragmatic approach, like this one: We take the limit of 53 (name limit in helm) and divide it by 2, minus 1 for the separator. That's 26. So we allow 26 characters for both cluster names and app names. Which means that an App resource name that is a combination of a cluster name and the app name, will have the maximum length of 26 + 1 + 26 = 53.

Visualized:

#########################-#########################

However, etcd-kubernetes-resources-count-exporter is 41 characters, so far more than this approach would allow.