TOSCA Native Service Orchestration SO State of the Union Dec. 12 , 2017 Santa Clara, CA DeWayne Filppi, Cloudify CTO Office

Agenda R1 Review: What happened, what didn’t R2 Preview: What’s next TOSCA Service Orchestration Modeling ONAP TOSCA Service Orchestration Modeling TOSCA in SO Trajectory

ONAP R1 SO TOSCA - Delivered Requirements and R1 Contributions ARIA must be callable from Camunda and/or seed code Contribution: REST API https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-server Contribution: ARIA Java Binding https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-java-client ARIA needs to fit in ONAP deployment model & be a microservice Contribution: ARIA Docker Image https://gerrit.onap.org/r/gitweb?p=so.git;a=blob;f=packages/docker/src/main/docker/docker-files/Dockerfile.aria ARIA needs to communicate with MultiVIM service Contribution: ARIA ONAP MultiVIM plugin https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/multivim-plugin vCPE use case TOSCA VNF vCPE infrastructure template (HEAT equiv) https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=tosca/vCPE/infra/base_vcpe_infra_rackspace_tosca.yaml

TOSCA Orchestrator in SO: ARIA ARIA TOSCA App Developer SDK ARIA Command Line Interface TOSCA App Development Guide CSAR Packager TOSCA Reference Example Templates ARIA Parser ARIA Store ARIA Workflow Engine TOSCA Simple Profile 1.0 Models Store Graph Declarative Workflows Imperative Workflows Artifacts Store TOSCA for NFV Profile 1.0(csd03) Built-in Declarative Workflows Storage Driver (sqlalchemy) ARIA Plugins Execution Plugins IaaS Plugins SDN Plugins NFV Plugins

ARIA DOCKER CONTAINER Made available on Dockerhub: cloudifyco:aria Features: Lightweight, uses Alpine base image Exposes REST API Built with Cloudify ARIA extensions Includes Cloudify plugins: Openstack AWS Will be available in Nexus Docker repo soon. May move outside of SO.

ONAP R1 SO TOSCA - Ambitions TOSCA Service Modeling Many tentacles/dependencies Modeling, SDC Internal (SO) discussions TOSCA VNF Infra Modeling HOT equivalent role Late compromise ECOMP merge

ONAP R2 SO TOSCA Minimum - HEAT ONAP Equivalence TOSCA VNF infra template in place of existing HOTs Inputs derived from TOSCA CSAR containing package Support of layered templates (TOSCA VF modules) IAAS Parent template Child template IAAS API Outputs Inputs MultiVIM

ONAP R2 SO TOSCA Full Integration With Core BPMN Approach: Post SDNC/OF fork Implications: ONAP TOSCA 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

The Critical Role of Modeling Standards In order to have model driven, you need: Models Models for services and VNFs Clear definition of VNF orchestration (VNFM?) ONAP TOSCA type definitions/vocabulary Without models, either: Model driven won’t happen, or Model driven will be hacked, or Model driven success will be declared

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

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 Types Template Main theme here is that there is a balance between service designer and service platform. Platform understanding of designer can determine which components will be meaningful for design. Horizon Hidden System Internals

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 OF APPC DCAE MultiVIM IAAS

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

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) Service orchestrations need to be constructable with knowledge of ONAP internals. Then the question becomes where to hide ONAP.

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 Uber base type? SDNC/OF Hiding Requires complete TOSCA model as input MultiVIM : TOSCA base types APPC & others: TOSCA base types This slide describes specific approaches for various projects that SO touches

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..) This slide describes specific approaches for various projects that SO touches

Realistic TOSCA Service Orchestration in ONAP Potential flow: SO SDC Template/CSAR DCAE TOSCA Orch. BPMN ONAP TOSCA Types VID ONAP TOSCA Types Get assgns Get assgns APPC ONAP TOSCA Types This slide describes specific approaches for various projects that SO touches AAI MultiVIM User Inputs SDNC OF

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