TOSCA Workflow Proposal Revision 5 TOSCA workflows Default

TOSCA Workflow Proposal Revision 5

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_v 2. 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>: target: <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>: target: <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, Block. Storage 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, Block. Storage 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 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 C: B C on-success: - D F D: E: on-success: D - C - F F: 8

Sample: tomcat Tomcat Requirements 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) compute started • Start tomcat after mysql even if no relation is specified between the two nodes Host mysql The workflow that creates the compute node until started state is delegated to the orchestrator Hosted. On My. SQL Requirements mysql creating tomcat creating mysql create tomcat create mysql created tomcat created mysql starting Host mysql start compute tosca. nodes. Compute Capabilities Container Hosted. On mysql started 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 9

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

Sample Install topology_template: workflows: preconditions: state: initial install: attributes: description: Workflow to deploy the application version: 10 steps: is_master: true Compute_install: activities: node: compute # defined in a node template elsewhere - set_state: creating preconditions: - call_operation: tosca. interfaces. node. lifecycle. Standard. create state: initial activities: - delegate: install on-success: serial: - Mysql_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: - set_state: created - set_state: starting - call_operation: tosca. interfaces. node. lifecycle. Standard. start - set_state: started on-success: - 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 - Tomcat_starting Mysql_initial: node: Mysql 11

Sample Backup topology_template: workflows: db_backup: node: db backup: preconditions: description: Workflow to backup the DB states: [ started, stopped ] # these are redundant with first steps: attributes: 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 version: 10 is_master: true activities: - set_state: tosca. interfaces. node. lifecycle. Standard. stopping - call_operation: tosca. interfaces. node. my. Backup - 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 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 12

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 13

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 nonhomogeneous states • Joining on cardinality • 1 • at least N 14

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

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

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

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

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 19

Declarative workflows improvements relationship_types: tosca. relationships. Connects. To: 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_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 20

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 21

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

Hosted. On - No. Op 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 23

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

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

Hosted. On (uninstall) 26

Hosted. On - No. Op 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 27

• Orchestrator can generate multiple workflows here as long as: Hosted. On software_2 Software Requirements Host software Hosted. On Software Requirements Host compute tosca. nodes. Compute Capabilities Container Hosted. On • software and 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()/conf igured/starting/started • The order of operations for the software_2 node are performed in normative order (creating/create()/created/configuring/configure()/conf igured/starting/started 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. 28

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

Hosted. On – example 1 topology_template: workflows: software_2_initial: target: software_2 install: activities: description: Workflow to deploy the application - set_state: creating steps: - call_operation: tosca. interfaces. node. lifecycle. Standard. create compute_install: - set_state: created target: compute - set_state: configuring activities: - call_operation: tosca. interfaces. node. lifecycle. Standard. configure - delegate: install on-success: - software_initial: - set_state: configured - set_state: starting - call_operation: tosca. interfaces. node. lifecycle. Standard. start - set_state: started 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 30

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

Hosted. On – example 2 topology_template: software_2_initial: target: software_2 workflows: activities: install: description: Workflow to deploy the application - set_state: creating steps: - call_operation: tosca. interfaces. node. lifecycle. Standard. create compute_install: - set_state: created target: compute - set_state: configuring activities: - call_operation: tosca. interfaces. node. lifecycle. Standard. configure - delegate: install on-success: - software_2_initial software_initial: target: software activities: - set_state: configured - set_state: starting - call_operation: tosca. interfaces. node. lifecycle. Standard. start - set_state: started on-success: - software_initial - 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 32

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

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

Hosted. On (uninstall) 35

Hosted. On 1 node on compute, scaling 36

Hosted. On (install) 37

Hosted. On (scale up) 38

Hosted. On (scale down) 39

Hosted. On (uninstall) 40

Depends. On 2 nodes connected together 41

42

Connects. To 2 nodes connected together 43

44

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