Open Stack

Hi Thomas,

Each of the two engines will be able to create resources in both regions.
We do not need to add anything in the heat client.

Right now when you want to create a new stack (using heat client or 
directly API) you need to provide:
- stack name
- template
- parameters (if need)
- tenant
- username
- password
- region name (optional)

The last four (tenant, username, password and region_name) we will call 
default context.
This context is used in Heat to configure all the openstack clients to 
other service.
Username, password and tenant is used for authentication.
Region name is use to get appropriate API endpoint from keystone catalog 
for other openstack service (like nova).
In case with one region you do not need to specify it because there is 
only one endpoint for each service.
In multi-region case we have more than one and region name is used to 
get correct one.

Each nested stack have its own set of openstack clients (nova client, 
neutron client, ... etc.) inside the heat engine.
Right now for all of them the default context is used to configure 
clients which will be used to create resources.
There is not option to change the default context for now. What I'm 
trying to do it to add possibility to define different
context inside the template file. New context can be passed to nested 
stack resource to create clients set with different
endpoints to call. Heat engine will get appropriate endpoints from 
keystone catalog for specified region name.

So from heat engine point of view there is not big change in the 
workflow. Heat will parse the template, create the
dependencies graph and start creating resources in the same way as 
usual. When he will need to created nested
stack with different context he will just use different set of openstack 
clients (ex. will call services in other region).

So to sum up each of the two heat engine will be able to create 
resources in both regions if different context will
be specified. If only default context will be used heat will create all 
resource in the same region where it is located.

Best,
Bartosz


On 11/15/2013 08:19 AM, Thomas Spatzier wrote:
> Hi Bartosz,
>
> one thing that is still not clear to me:
> In the discussion at the summit and in your updated architecture on the
> wiki it talks about two Heat engines, one in each region, and on-top only
> the dashboard. So what entity will really do the cross region
> orchestration? In the discussions I heard people talking about the heat
> client doing it. But wouldn't that duplicate functionality that is inside
> the engine into the client, i.e. the client would become an orchestrator
> itself then?
>
> Regards,
> Thomas
>
> Bartosz Górski <bartosz.gorski at ntti3.com> wrote on 14.11.2013 15:58:39:
>> From: Bartosz Górski <bartosz.gorski at ntti3.com>
>> To: openstack-dev at lists.openstack.org,
>> Date: 14.11.2013 16:05
>> Subject: [openstack-dev] [Heat] Continue discussing multi-region
> orchestration
>> Hi all,
>>
>> At summit in Hong Kong we had a design session where we discussed adding
>> multi-region orchestration support to Heat. During the session we had
>> really heated discussion and spent most of the time on explaining the
>> problem. I think it was really good starting point and right now more
>> people have better understanding for this problem. I appreciate all the
>> suggestions and concerns I got from you. I would like to continue this
>> discussion here on the mailing list.
>>
>> I updated the etherpad after the session. If I forgot about something or
>> wrote something that is not right feel free a please tell me about it.
>>
>> References:
>> [1] Blueprint:
>>
> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
>
>> [2] Etherpad:
>> https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud
>> [3] Patch with POC version: https://review.openstack.org/#/c/53313/
>>
>>
>> Best,
>> Bartosz Górski
>> NTTi3
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev