[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:
<snip>
>> 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.
Best,
-jay
More information about the OpenStack-dev
mailing list