On 07/29/2013 03:54 PM, Jay Pipes wrote:
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

I think it is a good start. I updated the wiki page with new concept with nested stack and context as a resource.

Right now I have a problem with the way how the template is passed to the nested stack. From what I see the only way right now is providing url to it and it is really annoying.
Is there any other way to do that?

Wiki page: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat


-jay


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to