TOSCA Workflow Proposal

1. TOSCA WorkflowProposal Revision 5

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

5. Full workflow override • Single activity per step • Or allow multiple sequential activities per step ?

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

7. Full workflow override • The on-successvalues 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 uninstallworkflow

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

9. Sample: The workflow that creates the compute node until started state is delegated to the orchestrator • 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) • Start tomcat after mysql even if no relation is specified between the two nodes compute started mysql creating tomcat creating mysql tomcat mysql create MySQL tomcat create Tomcat Requirements Requirements mysql created tomcat created Host Host mysql starting mysql start compute HostedOn HostedOn mysql started tosca.nodes.Compute Capabilities By default (need some additions for rolling upgrades) all instances must reach a state when a join (on-success) is defined. Container Tomcat starting tomcat start Tomcat started

10. 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 activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created on-success: - tomcat_starting mysql_initial: target: 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 Orchestrator internal init (all nodes initial state) element with no predecessor Sample Orchestrator can perform multipleoperations, change states to create the compute and bring it to started state compute_install compute started on-success on-success mysql_install tomcat_install tomcat creating mysql creating tomcat create mysql create tomcat created mysql 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 topology_template: workflows: install: description: Workflow to deploy the application steps: Compute_install: node: compute # defined in a node template elsewhere preconditions: state: initial activities: - delegate: install on-success: serial: - Mysql_initial - Tomcat_initial Tomcat_initial: node: tomcat preconditions: state: initial activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created on-success: - Tomcat_starting Mysql_initial: node: Mysql preconditions: state: initial attributes: version: 10 is_master: true 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 preconditions: state: initial requirements: - database_endpoint: available # vs unavailable activities: - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started

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

13. Issues • On-success • 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: • Node is in a state • All the required relationships are fulfilled • I.e. there is a notion of valid state for a node. • Operational constraints for a node state transition: • 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) • 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 a node activity: • Node has transitioned into the target state • The set of capabilities supported in the target state are available • Preconditions for a workflow: • 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 valid and supported transitions to move all nodes from the current state to the target state • Post conditions for a workflow: • 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

19. Declarative workflows improvements Work in progress

20. Declarative workflows improvements Work in progress

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. HostedOn - NoOp Software hosted on compute No scaling(template and instance workflows are the same) Note: We consider below an hosted on relationship that doesn’t implements any of the relationships operations

24. HostedOn (install) 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 software created tosca.nodes.SoftwareComponent software configuring Requirements Host software configure software configured compute HostedOn software starting tosca.nodes.Compute software start Capabilities Container software started

25. HostedOn (install) topology_template: workflows: install: description: Workflow to deploy the application steps: compute_install: target: compute activities: - delegate: install on-success: - software_initial software_initial: target: software 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

26. HostedOn(uninstall)

27. HostedOn - NoOp 2 Software hosted on same compute No scaling (template and instance workflows are the same) Note: We consider below an hosted on relationship that doesn’t implements any of the relationships operations

28. HostedOn • Orchestrator can generate multiple workflows here as long as: • softwareand software_2 have no concurrent operations • compute started is performed before software creating and software_2 creating • The order of operations for the software node are performed in normative order (creating/create()/created/configuring/configure()/configured/starting/start/started • The order of operations for the software_2 node are performed in normative order (creating/create()/created/configuring/configure()/configured/starting/start/started software software_2 Software Software Requirements Requirements Host Host compute HostedOn HostedOn tosca.nodes.Compute Capabilities Note: This constraints are guidelines and allow to ensure portability. By default workflows are generated without concurrent operations on the same compute node to avoid issues like concurrent apt-get or yum executions (that just fails). Workflow optimizers or users can however generate workflows that will perform concurrent operations. Theses workflows when included in the topologies (as full-workflows) will be portable. Container

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

30. HostedOn – example 1 topology_template: workflows: install: description: Workflow to deploy the application steps: compute_install: target: compute activities: - delegate: install on-success: - software_initial software_initial: target: software 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 on-success: - software_2_initial software_2_initial: target: software_2 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

31. HostedOn– example 2 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_2 creating software software_2 software create software_2 create Software Software Requirements Requirements software created software_2 created Host Host software configuring software_2 configuring software configure software_2 configure compute HostedOn HostedOn software configured tosca.nodes.Compute software_2 configured Capabilities software starting software_2 starting Container software start software_2 start software started software_2 started

32. HostedOn – example 2 topology_template: workflows: install: description: Workflow to deploy the application steps: compute_install: target: compute activities: - delegate: install on-success: - software_2_initial software_initial: target: software 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 software_2_initial: target: software_2 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 on-success: - software_initial

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

34. HostedOn – example 3 software_configure: target: software activities: - 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 on-success: - software_2_start software_2_initial: target: software_2 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 on-success: - software_configure software_2_start: target: software_2 activities: - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started topology_template: workflows: install: description: Workflow to deploy the application steps: compute_install: target: compute activities: - delegate: install on-success: - software_initial software_initial: target: software activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created on-success: - software_2_initial

35. HostedOn(uninstall)

36. HostedOn 1 node on compute, scaling

37. HostedOn(install)

38. HostedOn (scale up)

39. HostedOn(scale down)

40. HostedOn(uninstall)

41. DependsOn 2 nodes connected together

43. ConnectsTo 2 nodes connected together

45. ConnectsTo 2 nodes connected together One of the node is a substitution (impact on workflows)