Mistral/DSL
Contents
Mistral DSL specification
Version 0.1
Main objects
- Services
- Action
- Workflow
- Task
- Event
Services
Provides some specific functionality. For example, Nova service provides functionality for VMs management in OpenStack.
Attributes
All attributes are inside main keys of Services - services names
- type - currently we support the following types: RESTAPI, MISTRAL_REST_API, OSLO_RPC, this is a mandatory attribute
- parameters - dictionary depending on type of the service, this parameter can be optional. For example for REST API it should contain url of the service, method of authentication etc.
- actions - list of actions provided by this service
YAML example:
Services: Nova: type: REST_API parameters: key:value actions: create-vm: ...... delete-vm: .....
Action
A function provided by services. For example Nova service provides the following actions: create-vm, shutdown-vm
Attributes
- name - string without space, mandatory attribute
- parameters - dictionary, which structured is defined by service type. For REST service it contains url and method.
- task-parameters - dictionary containing parameters which should or could be specified in task
- response - dictionary containing keys 'select' and 'store_as'. Value for 'select' - YAQL expression and means what data action should extract as its result. Value for 'store_as' - string key which should be used for storing in the execution context
YAML example:
create-vm: parameters: url: servers task-parameters: name: optional: False response: select: '$.server.id' store_as: vm_id
Workflow
Attributes
- tasks - list of task in this workflow, each task represent some step in worflow
- events - list of events in workflow, e.g. timer or periodic events
YAML example:
Workflow: tasks: create-vms: ..... attache-volumes: .....
Task
Represents a step in workflow, for example attaching volume
Attributes
- name - string without space, mandatory attribute
- action - name of action to perform
- 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
- parameters - list of parameters
- 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
YAML example:
create-vms: action: Nova:create-vm parameters: image_id: 1234 flavor_id: 42 requires: task2: '$.value2 = 123' task4: '$.value4 = 122' on-success: task3
Events
By event it is possible to invoke specific task.
Attributes
- name - string without space, mandatory attribute
- type - can be PERIODIC, TIMER, CEILOMETER_ALARM
- tasks - list of tasks which should be execute on event
- parameters - list of parameters, defined by task
YAML example:
backup-vm: type: periodic tasks: [create_backup, delete_old_backup] parameters: time: 1 0 * * *
Full YAML example:
Workflow: tasks: runJob: requires: createVM: $.vm_ip != null action: DemoApp:runJob on-success: deleteVM on-error: sendJobError deleteVM: action: Nova:deleteVM on-finish: end sendJobError: action: std:email parameters: address: admin@mycompany.com subject: Workflow error body: Error occurred while running a VM job in execution {$.execution.id} on-finish: deleteVM # Creating a VM and waiting till it is up (an IP address has been assigned). createVM: action: Nova:createVM on-success: waitForIP on-error: sendCreateVMError waitForIP: action: std:repeat parameters: task: getIP retries: 5 delay: 3000 break-on: $.vm_ip != null on-finish: sendCreateVMError: $.vm_ip = null on-error: sendCreateVMError getIP: action: Nova:getIP sendCreateVMError: action: std:email parameters: address: admin@mycompany.com subject: Workflow error body: Failed to create a VM in execution {$.execution.id} on-finish: end # Terminal no-op task. end: action: Util:no-op events: runJob: type: periodic tasks: runJob parameters: cron-pattern: "*/1 * * * *" Services: Nova: type: REST_API parameters: baseUrl: {$.novaURL} actions: createVM: parameters: url: /servers/{$.vm_id} method: POST response: select: $.server.id store-as: vm_id getIP: parameters: url: /servers/{$.vm_id} method: GET response: select: $.server.accessIPv4 store-as: vm_ip deleteVM: parameters: url: /servers/{$.vm_id} method: DELETE DemoAPP: type: MISTRAL_REST_API parameters: baseUrl: http://{$.vm_ip}:8080/ actions: runJob: parameters: url: /runJob method: GET
Initial execution context
{ "novaURL": TBD, "imageID": TBD }
When a workflow starts Mistral also adds execution information into the context so the context looks like the following:
{ "novaURL": TBD, "imageID": TBD, "execution": { "id": "234234", "workbook_name" : "my_workbook", "project_id": "ghfgsdfasdfasdf" "auth_token": "sdfljsdfsdf-234234234", "trust_id": "oiretoilkjsdfglkjsdfglkjsdfg" } }