Is your feature request related to a problem? Please describe.
Despite each cluster typically having a user-friendly name, we often expose cluster UUIDs to users, which can be somewhat opaque and confusing.
Describe the solution you'd like
Presenting peerings, remote namespaces, etc. to the user with the user-friendly name; and letting the user address clusters by name, not only UUID
Describe alternatives you've considered
Solutions proposed so far and rejected:
Identifying clusters internally using the user-friendly name [rejected because of the possibility of two clusters having the same name]
Identifying clusters internally using the user-friendly name + random letters, the way Kubernetes objects work (e.g. polito-labinf => polito-labinf1-aoxwxj) [rejected because conflicts may still happen; k8s is able to pick a different name, we can't]
My 2 cents. I am wondering if we can simplify the problem having:
A unique UUID that identifies the cluster and the technical resources associated with the cluster (e.g., resourceOffer, resourceRequest).
A pretty local name associated with the UUID used to name the user-facing resources (e.g., node, foreign cluster).
@aleoli @giorio94 What do you think?
Is your feature request related to a problem? Please describe. Despite each cluster typically having a user-friendly name, we often expose cluster UUIDs to users, which can be somewhat opaque and confusing.
Describe the solution you'd like Presenting peerings, remote namespaces, etc. to the user with the user-friendly name; and letting the user address clusters by name, not only UUID
Describe alternatives you've considered Solutions proposed so far and rejected:
polito-labinf
=>polito-labinf1-aoxwxj
) [rejected because conflicts may still happen; k8s is able to pick a different name, we can't]Additional context