TOSCA workflows
TOSCA workflows
• Default workflow is declarative (generated from nodes and relationships)
• install
• at the beginning of install workflow all instances are in initial state.
• at the end of install workflow all planned instances must be in started state
• uninstall
• at the end of uninstall workflow all instances must be in deleted state
• Multiple solutions to allow users customize workflows
• Imperative
• Full override
• Partial override
• Declarative improvements
• Various solutions are not exclusive
2
Full workflow override
• Upsides
• Simple from orchestrator perspective
• User has a full-vision and understanding of the workflow
• No doubt on TOSCA default workflow weaving (dependencies and sequencing
between related nodes).
• Downsides
• Can be fastidious to write without tools
• Workflow is specific to a given topology template
3
Full workflow override
• Inspired by mistral
• http://docs.openstack.org/developer/mistral/dsl/dsl_v2.html
• Adapted for TOSCA
• Simplified declaration
• Simplification, no need for inputs and outputs that are already defined on
operations and using get_operation_output
4
• Single activity per step
Full workflow override
topology_template:
workflows:
<workflow_identifier>
description: <workflow_description>
inputs: <parameter_definition_list> # (can be used from operations using get_input as in standard topology template)
steps: # map of steps
<step_name>:
node: <node_name>
requirement: <relationship_name> # name of the requirement/relationship of the node
activity: # sequence of activities to be executed in a sequential way
<activity_type>: <activity_configuration>
on-success:
- <list of step names>
• Or allow multiple sequential activities per step ?
topology_template:
workflows:
<workflow_identifier>
description: <workflow_description>
inputs: <parameter_definition_list> # (can be used from operations using get_input as in standard topology template)
steps: # map of steps
<step_name>:
node: <node_name>
requirement: <relationship_name> # name of the requirement/relationship of the node
activities: # sequence of activities to be executed in a sequential way
- <activity_type>: <activity_configuration>
on-success:
- <list of step names>
5
Full workflow override
Activity type
description
delegate
Activity to be used when a node is not provided by a user but should be provided by the orchestrator
engine (Compute, BlockStorage etc.). For such node weaving operations of relationships that are not
also provided by the orchestrator should be prohibited.
set_state
Change the state of a node to a given state.
call_operation
Call the operation of the specified node (or one of it’s relationship). Inputs of the operation are
defined on the operation element.
• Delegate activity is important for portability in some use-cases
• Orchestrator to provide nodes (Compute, BlockStorage etc.) where
implementation can be specific
• Reusability of existing services (an existing Oracle DB on the cloud to be
matched against an abstract DB node in the topology one one cloud vs.
creating one on the fly on another cloud)
6
Full workflow override
• The on-success values are used to build the workflow graph. All
steps that have a on-success defined to a given step should be
executed before it (join).
• All steps that doesn’t have a predecessor are considered as initial step
and can run in parallel.
• All steps that doesn’t have a successor are considered as final.
• The TOSCA parser/validator SHOULD ensure that
• all nodes MUST reach the started state at the end of the install workflow
• all nodes MUST reach the deleted state at the end of the uninstall workflow
7
Full workflow override
steps:
A:
on-success:
A
- B
E
- C
B:
on-success:
- D
B
C:
C
on-success:
- D
F
D:
E:
on-success:
D
- C
- F
F:
8
The workflow that creates the
compute node until started state is
delegated to the orchestrator
Sample:
compute started
tomcat
Tomcat
mysql creating
tomcat creating
mysql create
tomcat create
mysql created
tomcat created
Requirements
Host
mysql
HostedOn
mysql starting
MySQL
Requirements
mysql start
Host
mysql started
compute
tosca.nodes.Compute
Capabilities
Container
HostedOn
This scenario aims to
• allow to perform tomcat’s creation in parallel of
mysql creation and start (bypass the single
concurrent operation per compute constraint)
Tomcat starting
tomcat start
Tomcat started
• Start tomcat after mysql even if no relation is
specified between the two nodes
9
topology_template:
workflows:
install:
Sample
description: Workflow to deploy the application
steps:
Compute_install:
target: Compute
activities:
- delegate: install
on-success:
- Mysql_initial
- Tomcat_initial
Tomcat_initial:
target: Tomcat
activities:
- set_state: creating
- call_operation: tosca.interfaces.node.lifecycle.Standard.create
- set_state: created
on-success:
- Tomcat_starting
Mysql_initial:
node: Mysql
Tomcat_starting:
activities:
target: Tomcat
- set_state: creating
activities:
- call_operation: tosca.interfaces.node.lifecycle.Standard.create
- set_state: starting
- set_state: created
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: starting
- set_state: started
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: started
on-success:
- Tomcat_starting
on-success:
- Tomcat_starting
10
Partial workflow override
Work in progress
• Upsides
• Easier to write if a user has no tool
• Downsides
• May be prone to errors as it may be harder to understand what will be added
or not by the TOSCA orchestrator (no automatic weaving should be done
between steps that are defined in an implicit workflow).
• Only for install and uninstall workflows ?
• Custom workflows and other scenarios will anyway probably require a full-workflow
describtion
• Workflow is specific to a given topology template
11
Partial workflow override
Work in progress
• Similar to full workflow override but you can have more than one partial workflow.
• Partial workflow let the orchestrator generate the workflow of nodes before the
topology_template:
workflows:
<workflow_identifier>
description: <workflow_description>
inputs: <parameter_definition_list> # (can be used from operations using get_input as in standard topology template)
partials:
steps: # map of steps for the partial workflow
<step_name>:
node: <node_name>
requirement: <relationship_name> # name of the requirement/relationship of the node
activities: # sequence of activities to be executed in a sequential way
- <activity_type>: <activity_configuration>
on-success:
- <list of step names>
12
Declarative workflows improvements (TOSCA-219)
• Upsides
• Can onboard ‘workflow updates’ on types and make them reusable (not
specific to a topology template)
• Downsides
• Less focused on reusability on a specific existing workflow for a specific
topology (need to get into TOSCA declarative workflow logic)
13
Declarative workflows improvements
• Add elements to instruct the declarative workflows for types
• Node Types
• Relationships Types
• Allow to override them on templates (like interfaces)
14
Declarative workflows improvements
Work in progress
node_types:
<node_type>:
workflows: # Defines the workflow for the given node.
<workflow_identifier>:
steps: # map of steps (you can even do some things in parallel for a single node if that make sense)
<step_name>:
activities: # sequence of activities to be executed in a sequential way
- <activity_type>: <activity_configuration>
on-success:
- <list of step names>
15
Declarative workflows improvements
Work in progress
node_types:
tosca.nodes.Root:
workflows:
install:
steps:
install_sequence:
activities:
- set_state: creating
- call_operation: tosca.interfaces.node.lifecycle.Standard.create
- set_state: created
- set_state: configuring
- call_operation: tosca.interfaces.node.lifecycle.Standard.configure
- set_state: configured
- set_state: starting
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: started
uninstall:
steps:
uninstall_sequence:
activities:
- set_state: stopping
- call_operation: tosca.interfaces.node.lifecycle.Standard.stop
- set_state: stopped
- set_state: deleting
- call_operation: tosca.interfaces.node.lifecycle.Standard.delete
- set_state: deleted
16
Declarative workflows improvements
relationship_types:
tosca.relationships.ConnectsTo:
workflow:
install: # name of the workflow for wich the weaving has to be taken in account
source_weaving: # Instruct how to weave some tasks on the source workflow (executed on SOURCE instance)
- after: configuring # instruct that this operation should be weaved after the target reach configuring
wait_target: created # add a join from a state of the target
activity: tosca.interfaces.relationships.Configure.pre_configure_source
- before: configured # instruct that this operation should be weaved before the target reach configured
activity: tosca.interfaces.relationships.Configure.post_configure_source
- before: starting
wait_target: started # add a join from a state of the target
- after: started
activity: tosca.interfaces.relationships.Configure.add_target
target_weaving: # Instruct how to weave some tasks on the target workflow (executed on TARGET instance)
- after: configuring # instruct that this operation should be weaved after the target reach configuring
after_source: created # add a join from a state of the source
activity: tosca.interfaces.relationships.Configure.pre_configure_target
- before: configured # instruct that this operation should be weaved before the target reach configured
activity: tosca.interfaces.relationships.Configure.post_configure_target
- after: started
activity: tosca.interfaces.relationships.Configure.add_source
Work in progress
state
state
state
state
17
Declarative workflows improvements
• TODO:
• Provide elements relative to instance model
• Scaled Apache node: each node has independent workflow
• Scaled Zookeeper node: Ideally I would like to wait that all zookeeper instances are
created before I do the configure operations
• Manage impacts and weaving of Groups interfaces for some clusters scenarios
18