Open Stack

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" <jorge.williams at rackspace.com> said:

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> 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
> <george.reese at enstratus.com><mailto:george.reese at enstratus.com> 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     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> 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 abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
>