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

Jay Pipes jaypipes at gmail.com
Mon Jul 29 13:54:03 UTC 2013

On 07/28/2013 08:04 PM, Angus Salkeld wrote:
> On 26/07/13 09:43 -0700, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2013-07-26 06:37:09 -0700:
>>> On 25/07/13 19:07, Bartosz Górski wrote:
>>> > We want to start from something simple. At the beginning we are
>>> assuming
>>> > no dependencies between resources from different region. Our first use
>>> > case (the one on the wikipage) uses this assumptions. So this is
>>> why it
>>> > can be easily split on two separate single region templates.
>>> >
>>> > Our goal is to support dependencies between resources from different
>>> > regions. Our second use case (I will add it with more details to the
>>> > wikipage soon) is similar to deploying two instances (app server + db
>>> > server) wordpress in two different regions (app server in the first
>>> > region and db server in the second). Regions will be connected to each
>>> > other via VPN connection . In this case configuration of app server
>>> > depends on db server. We need to know IP address of created DB
>>> server to
>>> > properly configure App server. It forces us to wait with creating app
>>> > server until db server will be created.
>>> That's still a fairly simple case that could be handled by a pair of
>>> OS::Heat::Stack resources (one provides a DBServerIP output it is passed
>>> as a parameter to the other region using {'Fn::GetAtt':
>>> ['FirstRegionStack', 'Outputs.DBServerIP']}. But it's possible to
>>> imagine circumstances where that approach is at least suboptimal (e.g.
>>> when creating the actual DB server is comparatively quick, but we have
>>> to wait for the entire template, which might be slow).
> How about we add an actual heat resource?
> So you could aggregate stacks.
> We kinda have one with "OS::Heat::Stack", but it doesn't use
> python-heatclient. We could solve this by adding an "endpoint"
>   property to the "OS::Heat::Stack" resource. Then if it is not
> local then it uses python-heatclient to create the nested stack
> remotely.
> Just a thought.

Eminently simple solution. +1


More information about the OpenStack-dev mailing list