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 endpoint). [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) http://dfw.servers.rackspace.com/v1.1/123/servers/12345 http://servers.osprovider.com/v1.1/456/servers/12345 http://servers.myos.com/v1.1/789/servers/12345 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. http://dfw.servers.rackspace.com/v1.1/12345/servers/rax:dfw:1:6789. 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, e.g. http://dfw.servers.rackspace.com/v1.1/12345/servers/6789.dfw.servers.racksp ace.com. 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 simplicity. 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): http://servers.myos.com/v1.1/12345/servers/5678.servers.myos.com http://servers.myos.com/v1.1/12345/servers/6789.dfw.servers.rackspace.com 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. Erik On 3/22/11 3:49 PM, "Eric Day" <e...@oddments.org> wrote: >See my previous response to Justin's email as to why UUIDs alone are >not sifficient. > >-Eric > >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 >>UUIDs? >> >> 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 >> bfsch...@gmail.com >> >> >> >> 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@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~openstack >> > More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > >_______________________________________________ >Mailing list: https://launchpad.net/~openstack >Post to : openstack@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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
