Jay is right. Standardizing on UUIDs doesn't mean that we have to expose them to the humans on a regular basis. With the namespace variant uuid5(), it is possible to regenerate the UUID given a namespace and a name.
The namespace could be the DNS/URL of the API service/zone and the name could be an auto-increment instance_id, reservation_id, volume_id, etc. Alternatively, the name could be the user_id concatenated with a user-provided name, given that names were checked for uniqueness for a given user when creating resources. As long as you are talking to the same API endpoint, you can convert easily to globally unique UUIDs internally. We do need globally unique immutable identifiers that can be generated in parallel by multiple API servers with low probability of collision, which means UUIDs in my opinion. Otherwise, every log file and accounting record will have to have a full URI to the resource to avoid naming ambiguities. RFC: http://tools.ietf.org/html/rfc4122.html and what Python gives you in the UUID class: http://docs.python.org/library/uuid.html Brian Schott [email protected] On Jun 2, 2011, at 3:40 PM, Jay Pipes wrote: > Yes, it's not easy to remember UUIDs. That's why virtually every > resource has some other way of identifying themselves. Typically, this > is a name attribute, though not all resources enforce uniqueness on > the name attribute, thus the need for a unique identifier. > > I don't see people manually looking up resources based on UUIDs. I see > *machines* manually looking up resources based on UUIDs, and humans > looking up resources by, say, name, or (name, tenant_id) or (name, > user_id), etc. > >> * And uniqueness across regions for "share nothing" can be managed with a >> variety of alternative options without resorting to the ugliness that is >> UUIDs > > Like URIs? I don't know of any other options that would work. Please > let us know what you think about in this respect. > > -jay > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
