openstack team mailing list archive

[Ed Leafe <ed@xxxxxxxxx>]

On Mar 23, 2011, at 1:55 AM, Eric Day wrote:

> If we provide some structure to the IDs, such as DNS names, we not only
> solve this namespacing problem but we also get a much more efficient
> routing mechanism.


	When I read things like this, the DBA in me winces a little. Meaningful PKs, compound PKs - they always end up being a Very Bad Thing. If you want to add efficient DNS routing, that could be added as additional data about an instance that is periodically updated up the zone structure along with the other capability information, but until now we've passed on that as a premature optimization. That was one of the major arguments in favor of the global DB design.

> Lets say you have api.rackspace.com (global aggregation zone),
> rack1.dfw.rackspace.com (real zone running instances), and
> bursty.customer.com (private zone). Bursty is a rackspace customer
> and they want to leverage their private resources alongside the
> public cloud, so they add bursty.customer.com as a private zone
> for their Rackspace account. The api.rackspace.com server now gets
> a terminate request for <id x> and it needs to know where to route
> the request. If we have a global namespace for instances (such as
> UUIDs), rack1.dfw.rackspace.com and bursty.customer.com could both
> have servers for <id x> (most likely from bursty spoofing the ID). Now
> api.rackspace.com doesn't know who to forward the request to.

	Even if this scenario were to happen, and nova tried to delete an instance with a spoofed ID that did *not* belong to Bursty, it would fail due to improper auth. Otherwise, even without zones/uuids/whatever, I could send termination requests to the API with random IDs and delete any machines with those IDs, whether I had rights to them or not. 

	In the current zone design, a request to terminate <id x> would not be handled by the outermost zone, since it wouldn't have instances, so it would be forward to each child zone. This would repeat down the zone hierarchy until either there were no more child zones, or a zone found that it had an instance with that ID. In the Bursty example, two zones would find an instance with that ID; one would fail due to auth, and the one owned by Bursty would be terminated as requested. The only way more than one instance would terminate would be if Bursty spoofed their own IDs, which would be their problem, not ours.


-- Ed Leafe