1. TOSCA Workflow Proposal
Revision 3

2. 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

3. 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

4. Full workflow override
Inspired by mistral
Adapted for TOSCA
Simplified declaration
Simplification, no need for inputs and outputs that are already defined on operations and using get_operation_output

5. Full workflow override
Single activity per step
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 activity: # sequence of activities to be executed in a sequential way
<activity_type>: <activity_configuration>
on-success:
- <list of step names>
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>

6. 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)

7. 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

8. Full workflow override
steps: A:
on-success:
- B
- C B:
- D C: D: E:
- F F: A E B C F D

9. Sample: compute started tomcat mysql creating tomcat creating
Requirements
Host
mysql creating
tomcat creating
mysql create
tomcat create
mysql created
tomcat created
HostedOn
mysql
MySQL
Requirements
Host
mysql starting
mysql start
mysql started
HostedOn
compute
tosca.nodes.Compute
Capabilities
Container
By default (need some additions for rolling upgrades) all instances must reach a state when a join (on-success) is defined.
Tomcat starting
tomcat start
Tomcat started

10. Sample compute started mysql creating tomcat creating mysql create
topology_template:
workflows:
install:
description: Workflow to deploy the application
steps:
compute_install:
target: compute # defined in a node template elsewhere
activities:
- delegate: install
on-success:
- mysql_initial
- tomcat_initial
tomcat_initial:
target: tomcat
- set_state: creating
- call_operation: tosca.interfaces.node.lifecycle.Standard.create
- set_state: created
- tomcat_starting
mysql_initial:
target: mysql
- set_state: starting
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: started
Orchestrator internal init (all nodes initial state)
element with no predecessor
Orchestrator can perform multiple operations, change states to create the compute and bring it to started state
compute_install
compute started
on-success
on-success
mysql_install
tomcat_install
mysql creating
tomcat creating
mysql create
tomcat create
mysql created
tomcat created
mysql starting
mysql start
on-success
mysql started
The on success flow implies a join: both mysql_install and tomcat_install must be completed before tomcat_starting is executed
on-success
tomcat_starting
Tomcat starting
tomcat start
Tomcat started
tomcat_starting:
target: tomcat
activities:
- set_state: starting
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: started
element with no successor
Install workflow end, all nodes are expected to be in started state

11. Sample Install preconditions: state: initial topology_template:
workflows:
install:
attributes:
description: Workflow to deploy the application
version: 10
steps:
is_master: true
Compute_install:
node: compute # defined in a node template elsewhere
preconditions:
state: initial
- set_state: starting
activities:
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- delegate: install
- set_state: started
on-success:
serial:
- Mysql_initial
Tomcat_starting:
- Tomcat_initial
target: tomcat
Tomcat_initial:
node: tomcat
requirements:
- database_endpoint: available # vs unavailable
- set_state: creating
- call_operation: tosca.interfaces.node.lifecycle.Standard.create
- set_state: created
- Tomcat_starting
Mysql_initial:
node: Mysql

12. Sample Backup preconditions: states: [ started, stopped ] attributes:
topology_template:
db_backup:
workflows:
backup:
description: Workflow to backup the DB
states: [ started, stopped ] # these are redundant with first step
steps:
node: db
is_master: true
preconditions:
states: [ started, stopped ]
- call_operation: tosca.interfaces.node.myBackup
attributes:
- set_state: tosca.interfaces.node.lifecycle.Standard.starting
is_master: true # backups are done using only the master DB node
- call_operation: tosca.interfaces.node.lifecycle.Standard.start
- set_state: started
version: 10
ws_start:
# TBD need to be able to specify client constraints across the WS to DB relationship
target: ws
on-success:
serial: # do the activies in serial order
state: stopped
requirements:
- ws_stop # might be nice to inline single lifecycle operations
- db_backup
- database_endpoint: available # vs unavailable Implicit but can control parallelism
- ws_start
ws_stop:
- set_state: starting
node: ws
state: started
activities:
- set_state: tosca.interfaces.node.lifecycle.Standard.stopping
- call_operation: tosca.interfaces.node.lifecycle.Standard.stop
- set_state: tosca.interfaces.node.lifecycle.Standard.stopped

13. Issues On-success Node Specification
Ordering is not specific. Parallel or serial? Need both
Also good time to add specification for node operation concurrency
Node Specification
Cardinality of nodes per templates not expressed
Template name implies all nodes created by the template
Should be able to specify subset of nodes created by the same template
By ordinal: 1, 2, …
Any subset: N
Should be able to express subset of nodes in the topology
E.g. restart the XXX service on all Linux servers running Ubuntu
Different kinds of processing for set of nodes created by the same template
E.g. treat master and slave differently
Should be able to specify different activities for different subsets of nodes

14. Pending use cases (not all listed)
Rolling update
Selecting a subset of nodes to down and update (an iterator on a workflow)
Creating additional nodes like M extra before downing the old ones
Stopping/starting upstream dependencies
Providing custom logic or pre-defined update strategies (???)
Cluster startup/shutdown
Joining on different subsets of nodes reaching specific sets of non- homogeneous states
Joining on cardinality 1
at least N

15. Workflow processing constraints
Preconditions for a node activity:
Post conditions for a node activity:
Node is in a state
Node has transitioned into the target state
All the required relationships are fulfilled
The set of capabilities supported in the target state are available
I.e. there is a notion of valid state for a node.
Preconditions for a workflow:
Operational constraints for a node state transition:
All the targeted nodes are in a state supported by the workflow (i.e. there are node activities which have the respective state pre-conditions)
There is a sequence of management operations able to transition the node from the current state to the target state for the current node state, property settings, attribute states, and requirement states AND does not change the state of any other node in the entire topology (less strictly, results in no detectable state change in any node or relationship in the entire topology once the transition is complete)
There is a sequence of valid and supported transitions to move all nodes from the current state to the target state
Post conditions for a workflow:
If a node transition caused a state in any other node (a nasty effect to be avoided), the activity must be refactored into a sequence of activities to adjust/manage the transition of the states of all affected nodes 
Post conditions for All nodes in the entire topology are satisfied

16. 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)

17. Declarative workflows improvements
Add elements to instruct the declarative workflows for types
Node Types
Relationships Types
Allow to override them on templates (like interfaces)

18. 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>

19. 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:
uninstall_sequence:
- 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
Group and clusters
- Mongo
Scalable single nodes
- Zookeeper

20. Declarative workflows improvements
Work in progress
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 state
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 state
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_source: created # add a join from a state of the source
activity: tosca.interfaces.relationships.Configure.pre_configure_target
activity: tosca.interfaces.relationships.Configure.post_configure_target
activity: tosca.interfaces.relationships.Configure.add_source

21. 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

22. Declarative to Full-workflow
Next slides will show examples on how the declarative model maps to the workflow model for normative nodes and relationships.

23. Software hosted on compute No scaling

24. tosca.nodes.SoftwareComponent
HostedOn
The orchestrator is responsible for managing any operation and states to bring the compute node in desired state.
Implementation may be orchestrator specific.
compute started
software creating
software create
software
tosca.nodes.SoftwareComponent
Requirements
Host
software created
software configuring
software configure
HostedOn
compute
tosca.nodes.Compute
Capabilities
Container
software configured
software starting
software start
software started

25. HostedOn topology_template: workflows: install:
description: Workflow to deploy the application
steps:
Compute_install:
target: Compute
activities:
- delegate: install
on-success:
- Mysql_initial
- Tomcat_initial
Tomcat_initial:
target: Tomcat
- 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

26. 2 Software hosted on same compute No scaling

27. HostedOn / Concurrency
tomcat
Tomcat
Requirements
Host
HostedOn
mysql
MySQL
Requirements
Host
HostedOn
compute
tosca.nodes.Compute
Capabilities
Container