Jump to: navigation, search

Difference between revisions of "Mistral/Cloud Environment Deployment details"

Line 1: Line 1:
=== Cloud Environment Deployment ===
+
<ref></ref>=== Cloud Environment Deployment ===
 
Cloud environment deployment procedure typically involves many steps that include infrastructure provision (instances, networks etc) and software installation and configuration. Those actions often depend on each other and thus need to be performed in some specific order. Also this process often involves more than one tool. This is a perfect fit for Mistral tasks-dependencies model.<br/>
 
Cloud environment deployment procedure typically involves many steps that include infrastructure provision (instances, networks etc) and software installation and configuration. Those actions often depend on each other and thus need to be performed in some specific order. Also this process often involves more than one tool. This is a perfect fit for Mistral tasks-dependencies model.<br/>
 
 
There are several approaches how cloud environment deployment can be addressed in OpenStack with Heat as a software orchestration tool:
 
There are several approaches how cloud environment deployment can be addressed in OpenStack with Heat as a software orchestration tool:
 
 
==== A. External approach ====
 
==== A. External approach ====
 
With this approach each task in tasks graph corresponds to some deployment action. Those may be infrastructure related tasks (like create instance) and software related task (like execute shell script on VM via SSH). Because we have Heat in OpenStack all infrastructure tasks can be done via addition (merging) of additional parts to Heat HOT templates. This can be achieved by built-in Mistral’s data flow capabilities. Besides HOT template building there must be also explicit task to create/update Heat stack with built template.
 
With this approach each task in tasks graph corresponds to some deployment action. Those may be infrastructure related tasks (like create instance) and software related task (like execute shell script on VM via SSH). Because we have Heat in OpenStack all infrastructure tasks can be done via addition (merging) of additional parts to Heat HOT templates. This can be achieved by built-in Mistral’s data flow capabilities. Besides HOT template building there must be also explicit task to create/update Heat stack with built template.
Line 9: Line 7:
 
Because Mistral is going to be integrated with Software Configuration Management (SCM) tools and because it can natively access various OpenStack REST APIs all of the tasks mentioned above can be performed by Mistral alone without a need for additional software to handle callback actions.
 
Because Mistral is going to be integrated with Software Configuration Management (SCM) tools and because it can natively access various OpenStack REST APIs all of the tasks mentioned above can be performed by Mistral alone without a need for additional software to handle callback actions.
 
The graph itself can be created either manually by a user of auto-generated using some third party tool. This can be useful for cloud deployment/management tools like PaaSes, software catalogs and other similar tools that wish to take advantage of Heat and SCM tools integration.
 
The graph itself can be created either manually by a user of auto-generated using some third party tool. This can be useful for cloud deployment/management tools like PaaSes, software catalogs and other similar tools that wish to take advantage of Heat and SCM tools integration.
 
 
==== B. Internal approach ====
 
==== B. Internal approach ====
 
Heat itself can use Mistral for processing HOT templates. With this approach components and resources directly map to Mistral tasks and Fn::GetAtt/hosten_on map to task dependencies. Handling of resource/component deployment remains in Heat but the order and context passing between those activities are delegated to Mistral. SCM integration may be done using Heat components but users also have ability to hook custom workflows to Heat-generated task graph.
 
Heat itself can use Mistral for processing HOT templates. With this approach components and resources directly map to Mistral tasks and Fn::GetAtt/hosten_on map to task dependencies. Handling of resource/component deployment remains in Heat but the order and context passing between those activities are delegated to Mistral. SCM integration may be done using Heat components but users also have ability to hook custom workflows to Heat-generated task graph.
Using Mistral for task-dependency tracking and context passing as well as task distribution may be a basis for Heat engine HA and further scalability. This also opens new possibilities for integration of Heat and 3rd party tools.<br/>
+
Using Mistral for task-dependency tracking and context passing as well as task distribution may be a basis for Heat engine HA and further scalability. This also opens new possibilities for integration of Heat and 3rd party tools.<br/><br/>
 
 
 
It is also possible to have both approaches simultaneously or some mix of them working together.
 
It is also possible to have both approaches simultaneously or some mix of them working together.

Revision as of 10:43, 31 October 2013

Cite error: Invalid <ref> tag; refs with no name must have content=== Cloud Environment Deployment === Cloud environment deployment procedure typically involves many steps that include infrastructure provision (instances, networks etc) and software installation and configuration. Those actions often depend on each other and thus need to be performed in some specific order. Also this process often involves more than one tool. This is a perfect fit for Mistral tasks-dependencies model.
There are several approaches how cloud environment deployment can be addressed in OpenStack with Heat as a software orchestration tool:

A. External approach

With this approach each task in tasks graph corresponds to some deployment action. Those may be infrastructure related tasks (like create instance) and software related task (like execute shell script on VM via SSH). Because we have Heat in OpenStack all infrastructure tasks can be done via addition (merging) of additional parts to Heat HOT templates. This can be achieved by built-in Mistral’s data flow capabilities. Besides HOT template building there must be also explicit task to create/update Heat stack with built template. Software configuration actions can be performed by execution of shell scripts, puppet manifests etc. on VM. Mistral’s data flow can help with passing data between software configuration tasks.
Because Mistral is going to be integrated with Software Configuration Management (SCM) tools and because it can natively access various OpenStack REST APIs all of the tasks mentioned above can be performed by Mistral alone without a need for additional software to handle callback actions. The graph itself can be created either manually by a user of auto-generated using some third party tool. This can be useful for cloud deployment/management tools like PaaSes, software catalogs and other similar tools that wish to take advantage of Heat and SCM tools integration.

B. Internal approach

Heat itself can use Mistral for processing HOT templates. With this approach components and resources directly map to Mistral tasks and Fn::GetAtt/hosten_on map to task dependencies. Handling of resource/component deployment remains in Heat but the order and context passing between those activities are delegated to Mistral. SCM integration may be done using Heat components but users also have ability to hook custom workflows to Heat-generated task graph. Using Mistral for task-dependency tracking and context passing as well as task distribution may be a basis for Heat engine HA and further scalability. This also opens new possibilities for integration of Heat and 3rd party tools.

It is also possible to have both approaches simultaneously or some mix of them working together.