openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

> From: Eric Day [eday@xxxxxxxxxxxx]
> > On Thu, Mar 24, 2011 at 12:23:42AM +0000, Sandy Walsh wrote:
> > 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. 

Hmm, yeah, you're right, the SSL cert approach should work for validating unique zone names. Funny, myself and pvo were talking about that route yesterday. 

But will it help us with the duplicates problem? ...

>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.

I'm not sure that's a good thing ... the use case I was thinking of is the customer using two providers:

The customer has his own Openstack deployment (range 0-1B) and outsources to Provider-A and Provider-B.
Sadly, Pro-A and Pro-B both use the default ID ranges for service providers (let's say 10-11B). 
The customer starts provisioning instances to both provider zones evenly ... pow, duplicates.

The customer won't be happy that sometimes he gets status on Instance 10,000,000,001 from Provider-A and sometimes from Provider-B. Or none at all.

If we append the DNS name of the provider, we bust RS 1.0 compatibility. 

Perhaps you can walk me through how you see the Cert check helping here (assuming no prefix on id)?
Or are we assuming that bursting is a RS x.0 API feature and things will change then?

-S

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.