Open Stack

Hi Bartosz,

Could you please clarify the section about resource creation in other
regions via calling their endpoints?

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

First of all, I believe this approach assumes that heat engine can reach
API endpoints which are located in different region. I am not sure if it is
a default deployment approach when someone is exposing OpenStack services
endpoints to the outside of the local DC network.

The same problem occurs with communication from VM to Heat engine. Heat
passes IP address for cloud watch, ceilometer and for signaling in order to
use waitcoinditions. So do you expect that VM will be able to communicate
with Heat engine who is in different location? That will assume that
networks in both locations are tightly coupled which is not the common case
I believe.

Thanks
Georgy


On Fri, Nov 15, 2013 at 9:24 AM, Bartosz Górski <bartosz.gorski at ntti3.com>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.
>
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/e5557db2/attachment.html>