← Back to team overview

openstack team mailing list archive

Re: Instance IDs and Multiple Zones


Good discussion.  I need to understand a bit more about how cross org
boundary bursting is envisioned to work before assessing the implications
on server id format.

Say a user hits the http://servers.myos.com api on zone A, which then
calls out to http://servers.osprovider.com api in zone B, which calls out
to http://dfw.servers.rackspace.com zone C, which calls down to
http://zoned.dfw.servers.rackspace.com zone D (which would not be a public

[We'll exclude authN and the network implications for now :->]

I assume the lowest zone (zone D) is responsible for assigning the id?

Does that mean there are now 4 URIs for the same exact resource (I'm
assuming a numeric server id here for a moment):

http://zoned.dfw.servers.rackspace.com/v1.1/123/servers/12345 (this would
be non-public)

I assume then the user is only returned the URI from the high level zone
they are hitting (http://servers.myos.com/v1.1/789/servers/12345 in this
example)?  If so, that means the high level zone defines everything in the
URI except the actually server ID which is assigned by the low level zone.
 Would users ever get returned a "downstream" URI they could hit directly?

Pure numeric ids will not work in a federated model at scale.  If you have
registered zone prefixes/suffixes, you will limit the total zone count
based on the number of digits you preallocate and need a registration
process to ensure uniqueness.  How many zones is enough?

You could use UUID.  If the above flow is accurate, I can only see how you
create collisions in your OWN OS deployment.  For example, if I
purposefully create a UUID collision in servers.myos.com (that I run) with
dfw.servers.rackspace.com (that Rackspace runs), it would only affect me
since the collision would only be seen in the servers.myos.com namespace.
Maybe I'm missing something, but I don't see how you could inject a
collision ID downstream - you can just shoot yourself in your own foot.
Eric Day, please jump in here if I am off.  AFAICT, same applies to dns
(which I will discuss more below).  I could just make my server ID dns
namespace collide with rackspace, but it would still only affect me in my
own URI namespace.

The other option apart from UUID is a globally unique string prefix.  If
Rackspace had 3 global API endpoints (ord, dfw, lon) each with 5 zones,
the ID would need to be something like rax:dfw:1:12345 (I would actually
want to hash the zone id "1" portion with something unique per customer so
people couldn't coordinate info about zones and target attacks, etc.).
This is obviously redundant with the Rackspace URI since we are
representing Rackspace and the region twice, e.g.

This option also means we need a mechanism for registering unique
prefixes.  We could use the same one we are proposing for API extensions,
or, as Eric pointed out, use dns, but that would REALLY get redundant,

Using strings also means people could make ids whatever they want as long
as they obeyed the prefix/suffix.  So one provider could be
rax:dfw:1:12345 and another could be osprovider:8F792#@*jsn.  That is
technically not a big deal, but there is something for consistency and

The fundamental problem I see here is URI is intended to be the universal
resource identifier but since zone federation will create multiple URIs
for the same resource, the server id now has to be ANOTHER universal
resource identifier.

Another issue is whether you want transparency or opaqueness when you are
federating.  If you hit http://servers.myos.com, create two servers, and
the ids that come back are (assuming using dns as server ids for a moment):



It will be obvious in which deployment the servers live.  This will
effectively prevent whitelabel federating.  UUID would be more opaque.

Given all of the above, I think I lean towards UUID.

Would love to hear more thought and dialog on this.


On 3/22/11 3:49 PM, "Eric Day" <eday@xxxxxxxxxxxx> wrote:

>See my previous response to Justin's email as to why UUIDs alone are
>not sifficient.
>On Tue, Mar 22, 2011 at 04:06:14PM -0400, Brian Schott wrote:
>> +1
>> Sounds like some IPV6 discussions back when the standards were being
>>debated.  We could debate bit-allocation forever.  Why can't we use
>> http://tools.ietf.org/html/rfc4122
>> """
>> 2.  Motivation
>>    One of the main reasons for using UUIDs is that no centralized
>>    authority is required to administer them (although one format uses
>>    IEEE 802 node identifiers, others do not).  As a result, generation
>>    on demand can be completely automated, and used for a variety of
>>    purposes.  The UUID generation algorithm described here supports very
>>    high allocation rates of up to 10 million per second per machine if
>>    necessary, so that they could even be used as transaction IDs.
>>    UUIDs are of a fixed size (128 bits) which is reasonably small
>>    compared to other alternatives.  This lends itself well to sorting,
>>    ordering, and hashing of all sorts, storing in databases, simple
>>    allocation, and ease of programming in general.
>>    Since UUIDs are unique and persistent, they make excellent Uniform
>>    Resource Names.  The unique ability to generate a new UUID without a
>>    registration process allows for UUIDs to be one of the URNs with the
>>    lowest minting cost.
>> """
>> Brian Schott
>> bfschott@xxxxxxxxx
>> On Mar 22, 2011, at 2:53 PM, Jay Pipes wrote:
>> > I know you don't want to resurrect a past discussion. But, UUIDs are
>> > designed to solve these kind of problems, frankly. The decision to go
>> > with integer IDs is a poor one, and will be negatively affecting the
>> > scalability and architecture of our systems well into the future.
>> > 
>> > I'd love to see a discussion around moving away from internal integer
>> > identifiers and towards UUID internal identifiers at the next summit.
>> > 
>> > Just my 2 cents,
>> > -jay
>> > 
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>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@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.

Follow ups