> From: Eric Day [e...@oddments.org] > > 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 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
