Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev