openstack team mailing list archive

[Thorsten von Eicken <tve@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>  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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp