-
Notifications
You must be signed in to change notification settings - Fork 238
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
Clarify Cluster ID, UUID, Name in API #106
Comments
Just to clarify, the installer uses its |
@csrwng put forth a slight change to my plan in separating the DNS from the naming, which would leave us with: Hive Cluster Deployment Name = Installer Cluster Name. It's used for tagging resources in AWS, both their Name tag as well as the k8s.io cluster tag. Generate name can be used if the particular deployment wants that additional randomness. Add SubdomainPrefix to both APIs, used for DNS when combined with -api.basedomain etc. Hive ClusterUUID = Installer ClusterID. (propose a rename to UUID in both) Does this seem clearer, and ok with your team @wking ? |
I don't want to speak for the rest of the installer folks. @abhinavdahiya, did you want to chime in here too?
I personally don't have much need for a name with an explicit goal of both human-recognition and uniqueness. If you want that, I'd rather you just stuffed it into
While we want this variable to hold a reasonably-unique ID, it only needs to be unique within an AWS account (or libvirt host, etc.). It doesn't have to be an RFC 4122 UUID (that's just what we happen to default to). So I'm ok with the current |
Ok another stab:
What would we use for the "name" tag on AWS resources? If installer generates a full UUID for ClusterID, this is not great. However if Hive passes it's semi-friendly ClusterID (foo-xlskj-pqosi) then this isn't so bad. Should the k8s cluster deployment name -> install config cluster name -> AWS resource name prefix? |
Would this be passed to the installer? I don't see an analog there now, but I'm obviously fine with you folks doing whatever you want internally ;).
This is fine with me. On the "is this just a prefix?" front, openshift/installer/pull/717 is landing an ingress config to use
Works for me, and this addresses my concerns about
Yeah, that addresses @joelddiaz's concerns about using opaque IDs in the tags by including a human-readable portion.
I'm not entirely clear on what you mean here. It sounds like you want to map your |
I think cluster deployment name -> install config metadata.name, and it should get used for AWS name tags. We can't use the ClusterID for those if the installer still uses a full UUID because standalone installer users should not login to aws and see UUIDs in names in the console. (regardless if Hive is working around it) Seem reasonable? |
But
I have no problem with users logging into AWS and seeing |
I thought we were both going to be adding SubdomainPrefix/DNSDomain, our config mirrors yours as much as possible and ideally we should probably stick pretty close together. This would leave your metadata.name largely unused though, so its probably fine if our SubdomainPrefix becomes your metadata.name. After discussion with @smarterclayton and @markturansky yesterday it sounds like we need to drop the functionality where callers can specify their UUID, always let the installer do it, and probably implicitly stick with UUIDs permanently. I'm ok with Being able to specify additional tags for AWS resources would be nice but we can look at in future. It's probably going to be more complexity than it's worth when it comes to cluster provisioned post-install resources. So in summary:
|
What are the friendly "name" tags? Things like this? |
No the literal "name" tags in AWS, i.e. the first thing you see when browsing in the AWS console on the leftmost column. |
Although I guess that is technically what you linked to becomes. :) |
A possible use case for custom tags: it's possible in aws to get cost allocation report broken down by tags: |
Looping back I think I'd like to move Hive's Spec.Config.ClusterID to Spec.Config.ClusterName, rather than SubdomainPrefix. It gets used in other ways and probably will continue to, that makes more sense to me with a more generic name. Any objections? |
Right now we have the cluster deployment name, a ClusterID, and a ClusterUUID.
The installer has a Name, and a ClusterID. Name is used in DNS in combination with the base domain.
Our ClusterUUID -> their ClusterID
Our ClusterID -> their cluster Name.
Our cluster deployment name is not used.
SD has raised a use case where name is not unique even within one account, as it could be combined with different base domains. As such we can't really map our cluster name to their cluster name. (We're going to need something validating uniqueness)
We should probably rename our ClusterID to ClusterName to eliminate the confusion around ClusterID in each API. Should we make it "DNSName" instead?
SHould we then rename our ClusterUUID to just ClusterID to match installer? Or is the UUID more precise and clear.
The result would be:
ClusterDeployment:
Name: foo-xldkj
DNSName: foo
BaseDomain: example.com
ClusterUUID: UUIDHERE
The text was updated successfully, but these errors were encountered: