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
