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 Adapted for TOSCA Simplified declaration Simplification, no need for inputs and outputs that are already defined on operations and using get_operation_output 4

Full workflow override topology_template: workflows: description: inputs: # (can be used from operations using get_input as in standard topology template) steps: # map of steps : node: requirement: # name of the requirement/relationship of the node activities: # sequence of activities to be executed in a sequential way - : on-success: - 5 topology_template: workflows: description: inputs: # (can be used from operations using get_input as in standard topology template) steps: # map of steps : node: requirement: # name of the requirement/relationship of the node activity: # sequence of activities to be executed in a sequential way : on-success: - Single activity per step Or allow multiple sequential activities per step ?

6 Activity typedescription delegateActivity 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_stateChange the state of a node to a given state. call_operationCall the operation of the specified node (or one of it’s relationship). Inputs of the operation are defined on the operation element. Full workflow override 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)

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 8 steps: A: on-success: - B - C B: on-success: - D C: on-success: - D D: E: on-success: - C - F F: A CB D E F

Sample: 9 compute tosca.nodes.Compute Capabilities Container HostedOn tomcat Tomcat Requirements Host mysql MySQL Requirements Host HostedOn compute started mysql creating tomcat creating mysql create mysql createdtomcat created tomcat create mysql start tomcat start mysql starting mysql started Tomcat starting Tomcat started

10 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 activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created on-success: - Tomcat_starting Mysql_initial: node: Mysql activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started on-success: - Tomcat_starting Tomcat_starting: target: tomcat activities: - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started on-success: - Tomcat_starting Sample

Partial workflow override 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 Work in progress

Partial workflow override 12 topology_template: workflows: description: inputs: # (can be used from operations using get_input as in standard topology template) partials: steps: # map of steps for the partial workflow : node: requirement: # name of the requirement/relationship of the node activities: # sequence of activities to be executed in a sequential way - : on-success: - 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 Work in progress

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 15 node_types: : workflows: # Defines the workflow for the given node. : steps: # map of steps (you can even do some things in parallel for a single node if that make sense) : activities: # sequence of activities to be executed in a sequential way - : on-success: - Work in progress

Declarative workflows improvements 16 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

Declarative workflows improvements 17 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: configuring # instruct that this operation should be weaved after the target reach configuring state 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 state activity: tosca.interfaces.relationships.Configure.post_configure_target - after: started activity: tosca.interfaces.relationships.Configure.add_source Work in progress