openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #01489
Re: Instance IDs and Multiple Zones
On Thu, Mar 24, 2011 at 12:23:42AM +0000, Sandy Walsh wrote:
> From: Eric Day [eday@xxxxxxxxxxxx]
> > Do we want this namespace per zone, deployment, resource owner, or some other dimension?
>
> Good question. We can prevent collisions at the zone level and within a deployment (single provider / multi-zone). But hybrid clusters are a different matter. Regardless of how we delineate it or which ID scheme we use, we have no way of detecting collisions.
Why not? Some schemes such as the ID.DNS name + ssl cert check I
mentioned before allow us to verify the authenticity of a namespace
before it is used. No other peer could register a zone with that
name unless the cert checks out. Within that zone Nova will prevent
collisions, but if things are really broken (accident or on purpose)
and it starts returning duplicate resource IDs, peer zones can choose
to just use one/none. We can document the behavior as undefined.
So, sure, you can still have duplicates within a zone (or other
namespace), but at least it's self contained and others peering with
it don't need to concern itself or worry about spoofing attacks within
it's own namespace.
> In the top-level zones of hybrid installations, all instances.get(id) calls issued would have to assume they could get back more than one instance. Ugly, but perhaps this is just the nature of the problem?
If we define the API for that call to only return a single instance,
it is up to the child zone to choose which one to send. If it tries
to return an array for a single ID, it would just be a protocol error
and fail.
-Eric
Follow ups