Jump to: navigation, search

Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat/The Missing Diagram"

(Pros)
(Pros)
Line 34: Line 34:
 
===== Pros =====
 
===== Pros =====
 
* Minimal code churn (only affects one resource type).
 
* Minimal code churn (only affects one resource type).
* Robust against failure of a whole region (available resources remain manageable).
+
* Robust against failure of a whole region (available resources remain manageable).  
 +
<-- 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)
  
 
===== Cons =====
 
===== Cons =====

Revision as of 19:07, 6 January 2014

The Missing Whiteboard 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
  • 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).
   <-- 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)
  • 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
  • Minimal code churn (only affects one resource type).
  • Robust against failure of a whole region (available resources remain manageable).

<-- 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)

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.