onap tosca orchestration with cloudify

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