Open Stack

On 11/15/2013 12:24 PM, Bartosz Górski wrote:
> 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.

One more step with the above and you might get to where I want you to
be, which is to be able to register an additional context myself, that
itself might have a specified endpoint, username, tenant and password.
Yup - so that I could run a heat in RAX and use that heat to orchestrate
resources in RAX and HP.

WOOT

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