Open Stack

Hi Sandy,

On Thu, Mar 24, 2011 at 01:01:18AM +0000, Sandy Walsh wrote:
> > From: Eric Day [eday at oddments.org]
> >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 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. 

I think this is fine. RS 1.0, just like the EC2 API, were not designed
with federation in mine. We should not try to jump through hoops to
force it if we have the luxury of defining the next API version and
supporting it more elegantly there.

As for backwards compatibility for RS 1.0/EC2, those APIs could
depend on a global mapping server for non-bursting zones to translate
nova-internal IDs (id.zone) to what they need (integer, etc.), but this
should not be a core component of Nova since it goes against our design
tenets. It should be deprecated (along with the APIs) and shutdown
in a timely manner once the new API and tools are available. Managing
resources in bursting zones would only be available through the new API
(along with other new features), so there will be plenty of incentive
for clients to change.

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

Yeah, the cert check verifies the zone nova.example.com can
return resource IDs named *.nova.example.com, all others should be
ignored. The ID's need the zone name suffix for it to make sense.

-Eric