Heat/Blueprints/Multi Region Support for Heat/The Missing Diagram



This diagram shows the possible options for multi-region support in Heat.

Region Silos
This is the current situation. Independent instances of Heat run in each region. It is up to the user to co-ordinate between stacks in different regions.

Pros

 * Simple.
 * Robust against failure of a whole region.

Cons

 * Where orchestration crosses regions, users must manage it themselves. We invented Heat so folks wouldn't have to do that.

Stack-based Multi-region
Independent instances of Heat runs in each region. When creating an OS::Heat::Stack resource (but only this type of resource), the user can specify a region. In this case, python-heatclient is used to connect to Heat in the appropriate region and create the substack.

Pros
<-- I don't think so. This architecture needs to be both heat in different region working. so It can't say Robust than the other solutions (Nachi)
 * Minimal code churn (only affects one resource type).
 * Robust against failure of a whole region (available resources remain manageable - you could even use stack adopt to reconstitute the global stack).
 * Same code can support pattern #3, e.g. in the case of a standalone global instance.

Cons

 * The user has to split their deployment into templates containing resources in only one region.
 * The user would have to run a standalone Heat instance to handle any regions not providing a Heat service.

Master Orchestrator
Independent instances of Heat runs in each region. In addition, there is a global Heat instance that crosses regions, and can create nested stacks in each of the regional Heat instances.

Pros
<-- I don't think so. This architecture needs to be both heat in different region working. so It can't say Robust than the other solutions (Nachi)
 * Minimal code churn (only affects one resource type).
 * Robust against failure of a whole region (available resources remain manageable).

Cons

 * Requires an extra Heat deployment that doesn't really belong anywhere in particular.
 * The user has to split their deployment into templates containing resources in only one region.
 * The global Heat has to run different code to the regional Heats.

Multi-Region resources
Independent instances of Heat runs in each region. However, the resources they manage may be in any region, regardless of the resource type.

Pros

 * Consistent across resource types.
 * Allows the user to construct their templates in any way they like.
 * Works even if Heat is not provided in every region.

Cons

 * Failure of the region containing the Heat stack leaves other resources unmanageable.
 * Getting instances to connect back to Heat may not even be possible.
 * Templates can be a confusing hodge-podge of resources in different regions.
 * Many relationships expressible within a single template are not actually possible.

Global Orchestrator
One global instance of Heat runs across all regions, and can manage resources in any region.

Pros

 * Consistent across resource types.
 * Allows the user to construct their templates in any way they like.

Cons

 * We'd have to turn Heat into a highly-available global service, which is insanely difficult.
 * Templates can be a confusing hodge-podge of resources in different regions.
 * Many relationships expressible within a single template are not actually possible.