I do not intend to suggest any disagreement on my part. In fact, I'm very happy for Thorsten's input here to help motivate this feature. However:
> Looks like the > implementation hasn't yet added support for that, but it will. Aren't we being a bit presumptuous? "Jorge Williams" <[email protected]> said: > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > The whole idea behind the "bookmark" links is to give you the functionality > that > you want -- that is a URL without a version number in it. Looks like the > implementation hasn't yet added support for that, but it will. > > -jOrGe W. > > On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote: > > We neither hate nor love UUIDs, but we like them when they provide value and > we > also accept alternatives. What we do hate is ambiguity and in certain cases > UUIDs > help. > > Look at the hrefs returned in this sample resource and picture what you'd > store in > your database as unique identifier to refer to each one: > {"server"=> > {"name"=>"kd_test_3", > > "flavorRef"=>"http://5.5.2.2:8774/v1.1/flavors/3<http://50.56.22.22:8774/v1.1/flavors/3>", > "addresses"=> > {"public"=>[], "private"=>[{"version"=>4, "addr"=>"5.5.2.5"}]}, > "metadata"=>{"v2"=>"d2", "4"=>"14", "5"=>"17"}, > > "imageRef"=>"http://<http://50.56.22.22:8774/v1.1/images/1>5.5.2.2<http://50.56.22.22:8774/v1.1/flavors/3>:8774/v1.1/images/1<http://50.56.22.22:8774/v1.1/images/1>", > "id"=>26, > "hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5", > "links"=> > > [{"href"=>"http://<http://50.56.22.22:8774/v1.1/servers/26>5.5.2.2<http://50.56.22.22:8774/v1.1/flavors/3>:8774/v1.1/servers/26<http://50.56.22.22:8774/v1.1/servers/26>", > "rel"=>"self"}, > > {"href"=>"http://<http://50.56.22.22:8774/v1.1/servers/26>5.5.2.2<http://50.56.22.22:8774/v1.1/flavors/3>:8774/v1.1/servers/26<http://50.56.22.22:8774/v1.1/servers/26>", > "rel"=>"bookmark", > "type"=>"application/json" > }, > > {"href"=>"http://<http://50.56.22.22:8774/v1.1/servers/26>5.5.2.2<http://50.56.22.22:8774/v1.1/flavors/3>:8774/v1.1/servers/26<http://50.56.22.22:8774/v1.1/servers/26>", > "rel"=>"bookmark", > "type"=>"application/xml" > } > ], > "status"=>"ACTIVE" > } > } > > Are the hostnames significant? Are the port numbers significant? Are the > version > IDs significant? Is the next URI component significant? Is the integer ID > significant? Mhhh, maybe it's obvious to the OpenStack implementers, but it > leaves > quite some room for error for all the users out there. We end up having to > write a > little algorithm that throws away the hostname and port, then throws away the > version number if there is one -- it really should NOT be part of the URL! -- > then > looks at the next path component to decide whether its the resource type and > whether the path component after that is the resource id, or whether there is > further nesting of path components. Then we can assemble a unique ID and see > whether we know about that resource or need to fetch it. It would be really > nice > to have a UUID attribute that eliminates this guesswork and we like UUIDs that > start with a type-specific prefix, such as inst-12345 or img-12345. > > Our recommendation: > - option 1: use canonical hrefs that can be used as unique IDs, which means > without host/port and without version number > - option 2: use a unique ID with a type prefix and include that as attribute > in > hrefs, we like small IDs, but we don't care that much > > WRT UUIDs, we try to use integer IDs when we can easily generate them > centrally, > but switch to UUIDs when we need to distribute the ID generation and we keep > them > as short as practical. > > Thanks much! > Thorsten - CTO RightScale > > > On 6/2/2011 12:40 PM, Jay Pipes wrote: > > On Thu, Jun 2, 2011 at 1:18 PM, George Reese > <[email protected]><mailto:[email protected]> wrote: > > > I hate UUIDs with a passion. > > * They are text fields, which means slower database indexes > > > Text fields are stored on disk/in memory as bytes the same as any > integer. It's that the number of bytes needed to store it is greater, > resulting in larger indexes and more bytes to store the keys. But, as > Jorge mentioned, some databases have native support for large-integer > types like UUIDs. > > > > * They are completely user-unfriendly. The whole "copy and paste" argument > borders > on silliness > > > 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]<mailto:[email protected]> > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : > [email protected]<mailto:[email protected]> > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at [email protected], and delete the original message. > Your cooperation is appreciated. > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
