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

Clint Byrum clint at fewbar.com
Fri Jul 26 16:43:31 UTC 2013


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).
> 

If you break that stack up into two stacks, db and "other slow stuff"
then you can get the Output of the db stack earlier, so that is a
solvable problem.

> > More complicated use case with load balancers and more regions are also
> > in ours minds.
> 
> Good to know, thanks. I'll look forward to reading more about it on the 
> wiki.
> 
> What I'd like to avoid is a situation where anything _appears_ to be 
> possible (Nova server and Cinder volume in different regions? Sure! 
> Connect 'em together? Sure!), and the user only finds out later that it 
> doesn't work. It would be much better to structure the templates in such 
> a way that only things that are legitimate are expressible. That's not 
> an achievable goal, but IMO we want to be much closer to the latter than 
> the former.
> 

These are all predictable limitations and can be handled at the parsing
level.  You will know as soon as you have template + params whether or
not that cinder volume in region A can be attached to the nova server
in region B.

I'm still convinced that none of this matters if you rely on a single Heat
in one of the regions. The whole point of multi region is to eliminate
a SPOF.



More information about the OpenStack-dev mailing list