onap tosca orchestration with cloudify
TRANSCRIPT
TOSCA Native Service Orchestration DesignDeWayne Filppi, Cloudify
2
Agenda
• Declarative vs Imperative Approaches• Brief TOSCA Concept Review• Service Orchestration Modeling• ONAP Service Orchestration Modeling• R1 Review• R2 and Beyond
3
Declarative vs Imperative : The false choice
• Declarative separates what from how• Declarative defines a model (what) and an orchestrator (how)• Model provides enough info for orchestrator to remain generic• Pros
- The allure of no coding- Orchestrator implementation hidden- Simple versionable artifact(s)- Designer focus on value/solution
• Examples: HOT, CloudFormation, TOSCA, Kubernetes, Docker Compose, etc...
4
TOSCA Concepts
• Defines modeler and orchestrator roles• Object modeling basis ( Java like )• Binds models to implementations (APIs)• Imperative workflows in orchestrator interpret runtime model instance
VM
Port
Net
Generic Install Workflow
1
3
2
5
TOSCA Concepts - Types
• Types can be viewed as OO classes• Concrete instances are called nodes• Service templates/models consists of nodes and relationships• Types are defined by:
- A name- Optional properties- Runtime properties (attributes)- Interfaces (the connection to type
specific imperative processing)- Requirements & Capabilities /
Relationships
web_app: type: WebApp properties: port: 9090 requirements: - host: web_server interfaces: Standard: configure: scripts/configure.sh start: scripts/start.sh stop: scripts/stop.sh
6
TOSCA Concepts - Interfaces & Operations
• Nodes can have behavior ( imperative )• Interfaces are the means. Interfaces have:
- Names (e.g. tosca.interfaces.Standard )- Operations, which have
• An operation name• A code reference (e.g. path to script)
• Workflows recognize interfaces
VM
Port
Net
Generic Install Workflow
1
3
2
Recognizes implemented interface tosca.interfaces.Standard
7
TOSCA Concepts - Relationships
• Relationships can be implicit or explicit• Types in their own right• Used by workflows to order operations• Used to execute arbitrary code
VM
Port
Net
Generic Install Workflow
1
3
2
Order operation execution based on relationships
8
TOSCA Concepts - Service Templates
• Service templates are node graphs ( DAGs)
• Service templates can define inputs/parameters
• Service instances are created from the combination of inputs and service templates
• Service instances have runtime state (attributes)
Inputs
Service Template
Service+
9
TOSCA Service Orchestration Modeling
• Higher level than VNF modeling• “Plane” thinking meets traversal orientation
- Data plane- Control plane- Infrastructure “plane”- Networking “plane”- App “plane”
• Critical consideration for ONAP
10
TOSCA Service Orchestration Modeling
• TOSCA implicitly defines a designer role
• Opposing pressures: what is visible to designer vs what does platform supply
• TOSCA capable of modeling arbitrary level
• Long running processes
Designer
TypesTemplate
Horizon
Hidden System Internals
11
TOSCA Service Orchestration in ONAP
• TOSCA typically models APIs as components- Nouns are types- Adjectives are properties- Verbs are operations
• ONAP has many APIs, and many potential types/components- SNDC, OF, MultiVIM, APPC, AAI,
etc…• Naive approach: TOSCA types
for everything
Designer
AAI SDNC
APPC
OF
MultiVIM
IAAS
DCAE
12
TOSCA Service Orchestration in ONAP
Naive Approach Problems• Exposes internals
- Knowledge problem- Binding problem
• AAI connected to all• SDNC & OF need entire
template as input
13
Realistic TOSCA Service Orchestration in ONAP
• Need orchestrations that are correct but designable• Designer shouldn’t have to care about ONAP internals• Hiding places:
- Base types- TOSCA Orchestrator Workflows- Behind the scenes BPMN- Other ONAP internal code (e.g. adapters)
14
Realistic TOSCA Service Orchestration in ONAP
• AAI Hiding- AAI interactions are ubiquitous- Service instance creation
• First step in SO service orchestration• Adapter, BPMN, or TOSCA workflow hiding
- MultiVIM interactions• Either in MultiVIM, or in TOSCA base types
• SDNC/OF Hiding- Requires complete TOSCA model as input- Adapter, BPMN, or TOSCA workflow hiding
• MultiVIM : TOSCA base types• APPC & others: TOSCA base types
15
Realistic TOSCA Service Orchestration in ONAP
TOSCA ONAP base types in depth• A base type provides interfaces workflows recognize
- An interface for AAI related components might include operations• register• unregister• with default implementations
• A base type provides common properties- A base type for APPC might include connection information (with defaults)
• A VNF base type would have properties common to all VNFs- User supplied config via template inputs
• MultiVIM types include IAAS basics (image, instance, network, etc..)
16
Realistic TOSCA Service Orchestration in ONAP
Potential flow:
SDC
ONAP TOSCA Types
ONAP TOSCA Types
ONAP TOSCA Types
Template/CSAR
SO
VID
User Inputs
BPMN
Get assgns
Get assgns
TOSCA Orch.
SDNC OF
AAI MultiVIM
APPC
DCAE
17
TOSCA Orchestrator in SO: ARIA
ARIA Parser
TOSCA Simple Profile 1.0
ARIA Workflow Engine
Graph Declarative Workflows
Imperative Workflows
ARIA Plugins
Execution Plugins
ARIA Command Line Interface
IaaSPlugins
ARIA TOSCA App Developer SDK
CSAR Packager
TOSCA Reference Example Templates
TOSCA App Development Guide
TOSCA for NFV Profile 1.0(csd03)
Built-in DeclarativeWorkflows
SDNPlugins
NFVPlugins
ARIA Store
Models Store
Artifacts Store
Storage Driver(sqlalchemy)
18
ONAP R1 SO TOSCA
▪○ https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-server
○https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-java-client
▪○
https://gerrit.onap.org/r/gitweb?p=so.git;a=blob;f=packages/docker/src/main/docker/docker-files/Dockerfile.aria
▪○
https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/multivim-plugin
▪○
https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=tosca/vCPE/infra/base_vcpe_infra_rackspace_tosca.yaml
Requirements and R1 Contributions
19
ONAP R2 SO TOSCA
Full Integration With Core BPMN• Approach: Post SDNC/OF fork• Implications:
- ONAP Base types for AAI, MultiVIM, APPC- Python APPC/DMaaP API- SDC ONAP Base type integration (potentially)- SDNC & OF ONAP types recognition/compatibility- SO/ARIA BPMN recognition and handoff (via inputs)
• includes mapping tenant info to ARIA template names & processing outputs- ONAP aware workflows (at least install/uninstall)- DCAE init ( BPMN or TOSCA workflow )- Enhance/complete ARIA REST API, improve microservice impl
• Minimum proof of work: pure TOSCA vCPE install/uninstall
20
ONAP SO TOSCA Trajectory
• Validate/explore via other use/edge cases• Track MultiVIM enhancements to true multi-cloud• Enhance ARIA container for use as Kubernetes service• Enhance ARIA availability/failure recovery• Healing/Scaling/CLAMP integration• Day 2+ custom workflow support• Downstream/southbound BPMN operation invocation
THANK YOU