ONAP TOSCA Orchestration with Cloudify
2 likes1,308 views
The document discusses TOSCA concepts and their application to service orchestration modeling in ONAP. It proposes using TOSCA to model ONAP's various APIs as components while hiding internal details from designers. Base types and workflows could abstract interactions with AAI, MultiVIM, APPC, and other ONAP components. The approach aims to allow correct orchestrations while avoiding exposing ONAP internals to designers.
ONAP TOSCA Orchestration with Cloudify
- 1. TOSCA Native Service Orchestration Design DeWayne Filppi, Cloudify
- 2. 2 Agenda • Declarative vs Imperative Approaches • Brief TOSCA Concept Review • Service Orchestration Modeling • ONAP Service Orchestration Modeling • R1 Review • R2 and Beyond
- 3. 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. 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. 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. 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. 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. 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. 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. 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 Types Template Horizon Hidden System Internals
- 11. 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. 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. 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. 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. 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. 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. 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 IaaS Plugins ARIA TOSCA App Developer SDK CSAR Packager TOSCA Reference Example Templates TOSCA App Development Guide TOSCA for NFV Profile 1.0(csd03) Built-in Declarative Workflows SDN Plugins NFV Plugins ARIA Store Models Store Artifacts Store Storage Driver (sqlalchemy)
- 18. 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. 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. 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
- 21. THANK YOU