[openstack-dev] [Heat] Continue discussing multi-region orchestration

Keith Bray keith.bray at RACKSPACE.COM
Fri Nov 15 21:17:38 UTC 2013

The way I view 2 vs. 4 is that 2 is more complicated and you don't gain
any benefit of availability.  If, in 2, your global heat endpoint is down,
you can't update the whole stack.  You have to work around it by talking
to Heat (or the individual service endpoints) in the region that is still

4 is much simpler in that only one Heat instance is involved.  If Heat is
down, you still have just as bad/good workaround, which is you talk to
service endpoints in the region that is still available.  If you want to
use Heat in that region to do it, you can Adopt the resources into a Heat
stack in that region. I don't see how 2 is "Robust against failure of
whole region" because if the region on the left part of the picture in 2
goes down, you can't manage your global stack or any of the resources in
the left region that are part of that global stack.  All you could manage
is a subset of resources by manipulating the substack in the right region,
but you can do this in 4 as well using Adopt.  4 is a simpler starting use
case and easier (IMO) for a user of the system to digest, and has the HUGE
advantage of being able to orchestrate deploying resources to multiple
regions without a service operator having to have Heat setup and installed
in EVERY region.  This is particular important for a private cloud/heat
person trying to deploy to public cloud.. If doing so requires the public
cloud operator have Heat running, then you can't deploy there.  If no Heat
in that region is required, then you can use your own instance of Heat to
deploy to any available openstack cloud.  That is a HUGE benefit of 4.


On 11/15/13 2:58 PM, "Zane Bitter" <zbitter at redhat.com> wrote:

>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
>> 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:
>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
>* 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.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list