Jump to: navigation, search

Difference between revisions of "Heat/Vision"

Line 1: Line 1:
'''
+
 
NOTE : The information below is for discussion, notes/diagram have not been produced by the current Heat core team, and in some cases do not represent an accurate picture of the current, or likely future architecture of Heat, thus this page should be considered a work-in-progress which we will gradually refine to reflect the true plan/vision as discussions within the core team and community continues during and after the design summit'''
+
''NOTE : The information below is for discussion, notes/diagram have not been produced by the current Heat core team, and in some cases do not represent an accurate picture of the current, or likely future architecture of Heat, thus this page should be considered a work-in-progress which we will gradually refine to reflect the true plan/vision as discussions within the core team and community continues during and after the design summit''
 +
--
  
 
During the Portland 2013 OpenStack Design Summit for Havana there was considerable discussion about what Heat's architecture could look like in the future. This block diagram attempts to illustrate the current thinking for how to accomplish a variety of future design goals. We plan to iterate gradually toward this vision. The new components are pictured in green. Purple means the end user host's this outside of Heat. Each are detailed below.
 
During the Portland 2013 OpenStack Design Summit for Havana there was considerable discussion about what Heat's architecture could look like in the future. This block diagram attempts to illustrate the current thinking for how to accomplish a variety of future design goals. We plan to iterate gradually toward this vision. The new components are pictured in green. Purple means the end user host's this outside of Heat. Each are detailed below.

Revision as of 20:25, 17 April 2013

NOTE : The information below is for discussion, notes/diagram have not been produced by the current Heat core team, and in some cases do not represent an accurate picture of the current, or likely future architecture of Heat, thus this page should be considered a work-in-progress which we will gradually refine to reflect the true plan/vision as discussions within the core team and community continues during and after the design summit --

During the Portland 2013 OpenStack Design Summit for Havana there was considerable discussion about what Heat's architecture could look like in the future. This block diagram attempts to illustrate the current thinking for how to accomplish a variety of future design goals. We plan to iterate gradually toward this vision. The new components are pictured in green. Purple means the end user host's this outside of Heat. Each are detailed below.

Heat-Vision.png

Alternate APIs

Heat will use an Open API and a related DSL as the common expression of an orchestration. A new solution pattern will be used for compatibility with alternate template formats, allowing implementations of various emerging cloud standards. Each may implement a Model Interpreter which will expose an appropriate service API, and decompose the given template into the common format. Once the resulting template has been generated in the open DSL format, the common API is triggered by the API Relay.

Model Interpreter

The concept of a Model Interpreter is introduced. This is a Heat system component that is responsible for parsing the DSL, and composing a deployment plan. It builds a graph of the deployment plan, and hands it off to a Scheduler. Alternate API's such as those pictured above as "API #2" and "API #N" could use the Model Interpreter component, or a variant of it.

Scheduler

Responsible for dispatching workflows through an arbitrary number of engine workers that coordinate stages of an orchestration.

Workflow Service

We see merit to the idea of a Workflow Service that would allow for a variety of functionality to be carried out for Heat. While Heat focuses on orchestration of resources, workflows are responsible for:

  • A sequence of tasks that have a start and end.
  • A persistent job/process (for example an Auto-Scale policy) that remains running until manually terminated.
  • A job to run for a specified duration (such as run this automated stress test for 2 days, then exit).


OpenStack services such as Nova or OpenStack Networking would have the option to use the Workflow Service directly in the case where reliable messaging is essential, and a single API call to another service is not sufficient to handle the need. For example, start this new network, and attach this list of servers to it.

Auto-Scale Service

Allows for scaling policies to be implemented. Ceilometer provides metrics from running servers and alerts that are passed to one or more user-defined webhook. This service is relatively lightweight, and provides a simple API for registering a new Auto-Scale Workflow along with the associated webhook(s). Any alerts or metrics from Ceilometer will be relayed to the webhooks.

User Defined CEP

The CEP is a user-defined Complex Event Processor that can apply arbitrary logic to determine what actions to take under various conditions, including triggering the Workflow Service, such as "add a node to this cluster", or orchestrations like "Deploy a new cluster" or combinations of each, such as "Destroy a failed cluster (workflow), and start up a new one (orchestration)".

The CEP is not hosted by Heat. It is provided by the user as an HTTP service that can accept a webhook call. This allows users to write them in the language of their choice, and implement whatever business logic suits their needs. Some example CEP solutions could be offered to do common auto-scale actions.

The justification for creating a CEP is that you may not want to trigger a scale-up workflow every time you get an alarm event from Ceilometer. You may want to control the rate at which actions are taken. You may consider using a simple ECA pattern, or possibly a more sophisticated MAPE pattern from Autonomic Computing.