On 15/11/13 18:24, 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.
So, to be clear, this is option (4) from the diagram I put together here:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
It's got a couple of major problems:
* When a whole region goes down, you can lose access to the Heat
instance that was managing still-available resources. This makes it more
or less impossible to use Heat to manage a highly-available global
application.
* Instances have to communicate back to the Heat instance that owns them
(e.g. for WaitConditions), and it's not yet clear that this is feasible
in general.
There are also a number of other things I really don't like about this
solution (listed on the wiki page), though reasonable people may disagree.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
