[openstack-dev] [Heat] Multi region support for Heat

Jay Pipes jaypipes at gmail.com
Mon Jul 29 17:36:24 UTC 2013

On 07/29/2013 01:21 PM, Zane Bitter wrote:
> On 29/07/13 17:40, Clint Byrum wrote:
>> There's an entirely good use case
>> for cross-region volumes and if it is ever implemented that way, and
>> cinderclient got some multi-region features, we wouldn't want users
>> to be faced with a big rewrite of their templates just to make use of
>> them. We should just be able to do the cross region thing now, because
>> we have that capability.
> This is interesting, because I think of Availability Zones within a
> Region as "things that are separated somewhat, but still make sense to
> be used together sometimes" and Regions as "things that don't make sense
> to be used together". So we have this three-tier system already (local,
> different AZ, different Region) that cloud providers can use to specify
> the capabilities of resources, yet we propose to make two of those tiers
> effectively equivalent? That doesn't sound like we are effectively
> modelling the problem domain.

I do not think of regions as "things that don't make sense to be used 
together". For example, if I have region A and region B and want to 
ensure that database cluster nodes are spun up in zones within both 
regions, why shouldn't I be able to do that with Heat?

> If we accept that distinction between AZs and Regions, then your example
> is, by definition, not going to happen. Presumably you don't accept that
> definition though, so I'd be curious to hear what everybody else thinks
> it means when a cloud provider creates a separate Region.

It means whatever the provider says it means. A region is not 
necessarily a geographic thing. For instance, you could have a region A 
that the provider says is their "utility" region -- with some level of 
bare-bones SLA for the service -- and a region B that the provider says 
is an "enterprise" region with some increased SLA. Heat should not make 
assumptions, however, that the two regions may not be used in the same 
fashion to create resources. Perhaps a tenant X wants to spin up 5 
instances in region B and have 10 instances in region A. Why not? Heat's 
templating/resource model should not prevent this from being possible.


More information about the OpenStack-dev mailing list