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.gor...@ntti3.com> wrote on 14.11.2013 15:58:39:
From: Bartosz Górski <bartosz.gor...@ntti3.com>
To: openstack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
