<div dir="ltr">Hi Bartosz,<div><br></div><div>Could you please clarify the section about resource creation in other regions via calling their endpoints?</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>So from heat engine point of view there is not big change in the workflow. Heat will parse the template, >create the</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>dependencies graph and start creating resources in the same way as usual. When he will need to created >nested</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>stack with different context he will just use different set of openstack clients (ex. will call services in other >region).</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>So to sum up each of the two heat engine will be able to create resources in both regions if different context >will </span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">be specified. If only default context will be used heat will create all resource in the same region where it >is located.</span><br>
</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 9:24 AM, Bartosz Górski <span dir="ltr"><<a href="mailto:bartosz.gorski@ntti3.com" target="_blank">bartosz.gorski@ntti3.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Thomas,<br>
<br>
Each of the two engines will be able to create resources in both regions.<br>
We do not need to add anything in the heat client.<br>
<br>
Right now when you want to create a new stack (using heat client or directly API) you need to provide:<br>
- stack name<br>
- template<br>
- parameters (if need)<br>
- tenant<br>
- username<br>
- password<br>
- region name (optional)<br>
<br>
The last four (tenant, username, password and region_name) we will call default context.<br>
This context is used in Heat to configure all the openstack clients to other service.<br>
Username, password and tenant is used for authentication.<br>
Region name is use to get appropriate API endpoint from keystone catalog for other openstack service (like nova).<br>
In case with one region you do not need to specify it because there is only one endpoint for each service.<br>
In multi-region case we have more than one and region name is used to get correct one.<br>
<br>
Each nested stack have its own set of openstack clients (nova client, neutron client, ... etc.) inside the heat engine.<br>
Right now for all of them the default context is used to configure clients which will be used to create resources.<br>
There is not option to change the default context for now. What I'm trying to do it to add possibility to define different<br>
context inside the template file. New context can be passed to nested stack resource to create clients set with different<br>
endpoints to call. Heat engine will get appropriate endpoints from keystone catalog for specified region name.<br>
<br>
So from heat engine point of view there is not big change in the workflow. Heat will parse the template, create the<br>
dependencies graph and start creating resources in the same way as usual. When he will need to created nested<br>
stack with different context he will just use different set of openstack clients (ex. will call services in other region).<br>
<br>
So to sum up each of the two heat engine will be able to create resources in both regions if different context will<br>
be specified. If only default context will be used heat will create all resource in the same region where it is located.<br>
<br>
Best,<br>
Bartosz<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/15/2013 08:19 AM, Thomas Spatzier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Bartosz,<br>
<br>
one thing that is still not clear to me:<br>
In the discussion at the summit and in your updated architecture on the<br>
wiki it talks about two Heat engines, one in each region, and on-top only<br>
the dashboard. So what entity will really do the cross region<br>
orchestration? In the discussions I heard people talking about the heat<br>
client doing it. But wouldn't that duplicate functionality that is inside<br>
the engine into the client, i.e. the client would become an orchestrator<br>
itself then?<br>
<br>
Regards,<br>
Thomas<br>
<br>
Bartosz Górski <<a href="mailto:bartosz.gorski@ntti3.com" target="_blank">bartosz.gorski@ntti3.com</a>> wrote on 14.11.2013 15:58:39:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Bartosz Górski <<a href="mailto:bartosz.gorski@ntti3.com" target="_blank">bartosz.gorski@ntti3.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.<u></u>org</a>,<br>
Date: 14.11.2013 16:05<br>
Subject: [openstack-dev] [Heat] Continue discussing multi-region<br>
</blockquote>
orchestration<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
At summit in Hong Kong we had a design session where we discussed adding<br>
multi-region orchestration support to Heat. During the session we had<br>
really heated discussion and spent most of the time on explaining the<br>
problem. I think it was really good starting point and right now more<br>
people have better understanding for this problem. I appreciate all the<br>
suggestions and concerns I got from you. I would like to continue this<br>
discussion here on the mailing list.<br>
<br>
I updated the etherpad after the session. If I forgot about something or<br>
wrote something that is not right feel free a please tell me about it.<br>
<br>
References:<br>
[1] Blueprint:<br>
<br>
</blockquote>
<a href="https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat" target="_blank">https://wiki.openstack.org/<u></u>wiki/Heat/Blueprints/Multi_<u></u>Region_Support_for_Heat</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[2] Etherpad:<br>
<a href="https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud" target="_blank">https://etherpad.openstack.<u></u>org/p/icehouse-summit-heat-<u></u>multi-region-cloud</a><br>
[3] Patch with POC version: <a href="https://review.openstack.org/#/c/53313/" target="_blank">https://review.openstack.org/#<u></u>/c/53313/</a><br>
<br>
<br>
Best,<br>
Bartosz Górski<br>
NTTi3<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>