TOSCA workflows.

Slides:



Advertisements
Similar presentations
Why Do We Need a (Plan) Portability API? Gerd Breiter Frank Leymann Thomas Spatzier.
Advertisements

Proposal by CA Technologies, IBM, SAP, Vnomic
Lecture # 2 : Process Models
TOSCA SugarCRM Deployment
TOSCA Workloads with OpenStack Heat-Translator
TOSCA Interoperability Demonstration
Apache Airavata GSOC Knowledge and Expertise Computational Resources Scientific Instruments Algorithms and Models Archived Data and Metadata Advanced.
Copyright © 2006 Pilothouse Consulting Inc. All rights reserved. Workflow Development Overview Architecture Requirements Types of workflows Stages of workflow.
Oracle Data Integrator Procedures, Advanced Workflows.
TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,
Objective: Enable portability and semi-automatic management of applications across clouds regardless of provider platform or infrastructure thus expanding.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
TOSCA Workflows Use Cases.
Introduction to OOAD and UML
TOSCA workflows. Default workflow is declarative (generated from nodes and relationships) install at the beginning of install workflow all instances are.
SDN-O LCM for Mercury Release Key Points and Overview
Joy Rathnayake Senior Architect – Virtusa Pvt. Ltd.
TOSCA Workflow Proposal
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Lesson # 9 HP UCMDB 8.0 Essentials
Essentials of UrbanCode Deploy v6.1 QQ147
Design Components are Code Components
Service Delivery and Governance
Provisioning of RAC Database on configured Stack
Unified Modeling Language
Behavioral Design Patterns
Multithreaded Programming in Java
Service Delivery and Governance
Activity and State Transition Diagram
OO Methodology OO Architecture.
Abstract Major Cloud computing companies have started to integrate frameworks for parallel data processing in their product portfolio, making it easy for.
AWS Batch Overview A highly-efficient, dynamically-scaled, batch computing service May 2017.
DF design as a node type.
OASIS TOSCA Report for December ONAP Modeling Workshop
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Contents Simulink model Grouping into subsystems Naming the subsystems
TOSCA Matching Or how the orchestrator provides implementation for abstract nodes or dangling requirements.
Cloud Application Marketplaces
DF design as a node type (output by Chris and shitao)
DF design as a node type (output by Chris and shitao)
Enhancements for Simple YAML Profile v1.2
TOSCA Workflow Proposal
20409A 7: Installing and Configuring System Center 2012 R2 Virtual Machine Manager Module 7 Installing and Configuring System Center 2012 R2 Virtual.
Weaving Abstractions into Workflows
Cloud Application Marketplaces
Instance Model Structure
Service Model Monitoring Cloud Application Marketplaces
Declarative Creation of Enterprise Applications
Cloud Application Marketplaces
Cloud Application Marketplaces
Cloud Application Marketplaces
Service Delivery and Governance
Presented By - Avinash Pawar
DF design as a node type (output by Chris and shitao)
Analysis models and design models
Cloud Application Marketplaces
Design Components are Code Components
Visual Modeling Using Rational Rose
Overview of Workflows: Why Use Them?
Applying Use Cases (Chapters 25,26)
CAD DESK PRIMAVERA PRESENTATION.
TOSCA v1.3 Enhancements February 21, 2019.
Cloud Application Marketplaces
Controller Design Studio – Architecture & Design
Computational Pipeline Strategies
Frieda meets Pegasus-WMS
WP3: BPaaS Research Execution Environment
Task 55 Scope – TOSCA Profile
From Use Cases to Implementation
TOSCA Orchestration Paradigm
Presentation transcript:

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

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

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

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>

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)

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

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

Sample: The workflow that creates the compute node until started state is delegated to the orchestrator compute started tomcat Tomcat 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 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 Tomcat starting tomcat start Tomcat started

Sample Delegating can be a mapping. 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 - Tomcat_starting Mysql_initial: node: Mysql - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started Sample Tomcat_starting: target: Tomcat activities: - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started on-success: - Tomcat_starting Delegating can be a mapping. Think about convention for sure naming

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

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>

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)

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

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>

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

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

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