<div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Pure numeric ids will not work in a federated model at scale. <br></blockquote><div><br></div><div>Agreed</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Maybe I'm missing something, but I don't see how you could inject a<br>
collision ID downstream - you can just shoot yourself in your own foot.</span></blockquote><div><br></div><div>I think that you can get away with it only in simple hierarchical structures. Suppose cloud users are combining multiple public clouds into their own 'megaclouds'. If I'm an evil public cloud operator, I can start handing out UUIDs that match any UUIDs I can discover on the Rackspace cloud, and anyone that has constructed a cloud that combines my cloud and Rackspace would have collisions. Users wouldn't easily know who to blame either.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The other option apart from UUID is a globally unique string prefix. If<br>
Rackspace had 3 global API endpoints (ord, dfw, lon) each with 5 zones,<br>
the ID would need to be something like rax:dfw:1:12345 (I would actually<br>
want to hash the zone id "1" portion with something unique per customer so<br>
people couldn't coordinate info about zones and target attacks, etc.).<br>
This is obviously redundant with the Rackspace URI since we are<br>
representing Rackspace and the region twice, e.g.<br>
<a href="http://dfw.servers.rackspace.com/v1.1/12345/servers/rax:dfw:1:6789" target="_blank">http://dfw.servers.rackspace.com/v1.1/12345/servers/rax:dfw:1:6789</a>.<br></blockquote><div><br></div><div>I am in favor of this option, but with a few tweaks:</div>
<div><br></div><div>1) We use DNS, rather than inventing and administering our own scheme</div><div>2) I think the server ID looks like <a href="http://dfw.rackspace.com/servers/a282-a6-cj7aks89">dfw.rackspace.com/servers/a282-a6-cj7aks89</a>. It's not necessarily a valid HTTP endpoint, because there's a mapping to a protocol request</div>
<div>3) The client maps it by "filling in" the http/https protocol (or whatever protocol it is e.g. direct queuing), and it fills in v1.1 because that's the dialect it speaks.</div><div>4) Part of the mapping could be to map from a DNS name to an endpoint, perhaps using _srv records (I'm sure I'm mangling all the terminology here)</div>
<div>5) This also allows a form of discovery ... if I tell my cloud controller I want to use <a href="http://rackspace.com">rackspace.com</a>, it can then look up the _srv record, find the endpoint (e.g. <a href="http://openstack.rackspace.com">openstack.rackspace.com</a>), then do a zone listing request and find child zones etc. If I ask my monitoring system to monitor "<a href="http://rackspace.com/servers/a6cj7aks89">rackspace.com/servers/a6cj7aks89</a>", it knows how to map that to an openstack endpoint. Auth is another story of course.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Using strings also means people could make ids whatever they want as long<br>
as they obeyed the prefix/suffix. So one provider could be<br>
rax:dfw:1:12345 and another could be osprovider:8F792#@*jsn. That is<br>
technically not a big deal, but there is something for consistency and<br>
simplicity.</blockquote><div><br></div><div>True. We could restrict the character set to A-Z,0-9 and a few other 'safe characters' if this is a real problem. We probably should eliminate difficult-to-encode characters anyway, whether encoding means umlauts or url-encoding.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The fundamental problem I see here is URI is intended to be the universal<br>
resource identifier but since zone federation will create multiple URIs<br>
for the same resource, the server id now has to be ANOTHER universal<br>
resource identifier.<br></blockquote><div><br></div><div>I think the server ID should be the unique identifier, and is more important than the REST representation. I think we should avoid remapping the URI unless we have to... (more later)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It will be obvious in which deployment the servers live. This will<br>
effectively prevent whitelabel federating. UUID would be more opaque.<br></blockquote><div><br></div><div>Whitelabel federation for reselling an underlying provider can easily be done by rewriting strings: id.replace("<a href="http://rackspace.com">rackspace.com</a>", "<a href="http://a.justinsbcloud.com">a.justinsbcloud.com</a>").replace("<a href="http://citrix.com">citrix.com</a>", "<a href="http://b.justinsbcloud.com">b.justinsbcloud.com</a>"). I suspect the same approach would work for internal implementation zones also. The truly dedicated will discover the underlying structure whatever scheme you put in place.</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Would users ever get returned a "downstream" URI they could hit directly?<br></blockquote><div><br></div><div>So now finally I think I can answer this (with my opinion)... Users should usually get the downstream URI. Just like DNS, they can either use that URI directly, or - preferably - use a local openstack endpoint, which acts a bit like a local DNS resolver. Your local openstack "proxy" could also do things like authentication, so - for example - I authenticate to my local proxy, and it then signs my request before forwarding it. This could also deal with the billing issue - the proxy can do charge-back and enforce internal spending limits and policies, and the public clouds can then bill the organization in aggregate.</div>
<div><br></div><div>If you need the proxy to sign your requests, then you _can't_ use the downstream URI directly, which is a great control technique.</div><div><br></div><div>Some clouds will want to use zones for internal operational reasons, and will want to keep the inner zones secret. So there, we need something like NAT: the front-end zone translates between "public" and "private" IDs as they travel in and out. How that translation works is deployment-dependent... they could have a mapping database, or could try to figure out a function which is aware of their internal structure to do this algorithmically.</div>
<div><br></div><div>Let me try an example:</div><div><br></div><div>Consider someone like Rackspace. Rackspace has geographically distributed datacenters: DFW, ORD, LON etc In addition, within each datacenter there will be public sub-zones (floor1, floor2, floor3), so I can be sure that my failover machine isn't on the same switch or host as my primary. Then, a public sub-zone may have further private sub-zones for operational reasons - room1, room2, room3.</div>
<div><br></div><div><a href="http://rackspace.com">rackspace.com</a></div><div> ORD<br></div><div> ...</div><div> LON</div><div> ...</div><div> DFW</div><div> floor1</div><div> ...</div>
<div> floor2</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div> ...</div><div> floor3</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div> room1</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div> room2</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div> room3</div><div> </div><div>Now, I don't want room1, room2 and room3 to be visible, for whatever reason. So the parent zone remaps child resources as they pass through, so room1/AB => 1AB and room2/CD <=> 2CD (keeping it simple!)</div>
<div><br></div><div>The floors are customer visible, so I can either do floor1.???/servers/2CD or ???/servers/floor1/2CD. I think the determining factor is that here I don't want customers hitting the floor1 endpoint directly (I probably haven't exposed it), so I choose the latter: ???/servers/floor1/2CD</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>I have the same choice again at the datacenter level. dfw.???/servers/floor1/2CD or ???/servers/dfw/floor1/2CD. Here, I think I probably want to allow customers to hit the DFW endpoint directly, so I choose the former: dfw.???/servers/floor1/2CD</div>
<div><br></div><div>I want dfw.??? to resolve to the endpoint (possibly via an _srv record), so it is <a href="http://dfw.rackspace.com">dfw.rackspace.com</a>, so our server ID is: <a href="http://dfw.rackspace.com/servers/floor1/2CD">dfw.rackspace.com/servers/floor1/2CD</a> </div>
<div><br></div><div>Rackspace can also choose to operate a cloud-aggregator endpoint <a href="http://rackspace.com">rackspace.com</a>, which combines all the datacenters into a unified view. If I pass it a server ID like <a href="http://dfw.rackspace.com/servers/floor1/2CD">dfw.rackspace.com/servers/floor1/2CD</a>, it knows immediately to forward it to the <a href="http://dfw.rackspace.com">dfw.rackspace.com</a> endpoint. It doesn't need to rewrite this ID... there's no reason to do so. If something directly hit the <a href="http://dfw.rackspace.com">dfw.rackspace.com</a> endpoint that actually needed to take place "globally", DFW could forward the request "up" (I'm not sure whether this would actually happen in practice - maybe a cross-datacenter migration)</div>
<div><br></div><div>The beauty is that the <a href="http://rackspace.com">rackspace.com</a> proxy is largely the same code as a private cloud proxy, which is much the same code as the zone controllers at every level. There are some differences in terms of whether we're remapping IDs, but those differences are relatively small. (Imaginary coding is always easy though!)</div>
<div><br></div><div>A potential tricky issue is in e.g. the cloudbursting scenario, when a user gets a cloud server; should they get a remapped ID or not, if we want them always to go through a proxy (e.g. for auth/billing)? I think there are two viable answers here. Either they should always get the 'true' ID, but the client needs to have a config option that says 'always hit the local proxy endpoint'. Or the local proxy should remap it if it isn't happy with relying on clients to get it right... so <a href="http://dfw.rackspace.com/servers/floor1/2CD">dfw.rackspace.com/servers/floor1/2CD</a> becomes <a href="http://cloud.megacorp.com/servers/dfw.rackspace.com/servers/floor1/2CD">cloud.megacorp.com/servers/dfw.rackspace.com/servers/floor1/2CD</a>. I think I prefer the latter - less scope for error.</div>
<div><br></div><div><br></div><div>Justin</div><div><br></div></div></div>