Open Stack

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.