Difference between revisions of "Mistral/DSLv2"
(→Related Links) |
|||
Line 16: | Line 16: | ||
=== Related Links === | === Related Links === | ||
− | * YAML: http://yaml.org | + | * Yet Another Markup Language (YAML): http://yaml.org |
− | * YAQL: https://pypi.python.org/pypi/yaql/0.3 | + | * Yet Another Query Language (YAQL): https://pypi.python.org/pypi/yaql/0.3 |
=== Workflows === | === Workflows === |
Revision as of 22:21, 23 September 2014
Contents
- 1 Mistral DSL version 2 specification
Mistral DSL version 2 specification
Introduction
Current document fully describes Domain Specific Language (DSL) version 2 of Mistral Workflow Service. Since version 1 issued in May 2014 Mistral team completely reworked the language pursuing with the goal in mind to make it easier to understand while more consistent and flexible.
Mistral DSL is fully based on YAML and knowledge of YAML is a plus for better understanding of the material of this specification.
Unlike Mistral DSL v1 this second version of DSL assumes that all entities that Mistral works with like workflows, actions and triggers are completely independent in terms of how they're referenced and accessed through API (and also Python Client API and CLI). Workbooks, the entity that can combine combine workflows/actions/triggers still exist in the language but only for namespacing and convenience purposes. See Workbooks section for more details.
All DSL consists of the following main object(entity) types that will be described in details next:
Related Links
- Yet Another Markup Language (YAML): http://yaml.org
- Yet Another Query Language (YAQL): https://pypi.python.org/pypi/yaql/0.3
Workflows
Workflow is the main building block of Mistral DSL, the reason why the project exists. Workflow represents a process that can be described in a various number of ways and that can do some job interesting to the end user. Each workflow consists of tasks (at least one) describing what exact steps should be made during workflow execution.
YAML example
create_vm: type: direct input: - vm_name - image_ref - flavor_ref output: vm_id: $.vm_id tasks: create_server: action: nova.servers_create name={$.vm_name} image={$.image_ref} flavor={$.flavor_ref} publish: vm_id: $.id on-success: - wait_for_instance wait_for_instance: action: nova.servers_find id={$.vm_id} status='ACTIVE' policies: retry: delay: 5 count: 15
Workflow Types
Mistral DSL v2 introduces different workflow types and the structure of each workflow type varies according to its semantics. Currently, Mistral provides two workflow types:
See corresponding sections for details.
Common Workflow Attributes
- type - Workflow type. It can be either 'direct' or 'reverse'.
- input - list of required input parameter names.
- output - any data structure arbitrarily containing containing YAQL expressions that defines workflow output.
- task-defaults - TODO
- tasks - TODO
Tasks
TODO
Common Task Attributes
- action - name of action to run
- workflow - name of workflow to run
- input - actual parameters for the task, each value can be either some number, string etc, or YAQL expression to retrieve value from task context
Direct Workflow
TODO
YAML example
TODO
Attributes
- tasks - list of tasks in this workflow, each task represents a computational step in the workflow.
Direct Workflow Task Attributes
TODO
- on-success - task which will be scheduled on execution after current task has finished with state 'SUCCESS'
- on-error - task which will be scheduled on execution after current task has finished with state 'ERROR'
- on-finish - task which will be scheduled on execution after current task has finished
Reverse Workflow
TODO
YAML example
TODO
Attributes
- tasks - list of tasks in this workflow, each task represents a computational step in the workflow.
Reverse Workflow Task Attributes
TODO
- requires - list of tasks which should be execute before this tasks, or list of task names as a keys and condition as a value, this is optional parameter
Actions
TODO: Mention system and ad-hoc actions
System Actions
TODO
Ad-hoc actions
TODO
YAML example
TODO
Attributes
- name - action name (string without space, mandatory attribute).
- base - name of base action that this action is built on top of.
- base-input - dictionary whose structure is defined by action class. For example, for 'std.http' action it contains 'url', 'method', 'body' and 'headers' according to HTTP protocol specification.
- input - list containing parameter names which should or could be specified in task. This attribute is optional and used only for documenting purposes.
- output - any data structure defining how to transform the output of base action into the output of this action. I can optionally have YAQL expressions to access properties of base action output.
Triggers [coming in version 0.2.0]
NOTE: Triggers are not yet implemented as part of version 0.1.0, they will go into 0.2.0
Using triggers it is possible to run workflows according to specific rules: periodically setting a cron (http://en.wikipedia.org/wiki/Cron) pattern or on external events like ceilometer alarm.
YAML example
TODO
Attributes
TODO
Workbooks
TODO
YAML example
TODO
Attributes
TODO