TOSCA ONAP Service Orchestration with Cloudify and ARIA

The ONAP (Open Network Automation Platform) represents the merger of the Open-O and Open-ECOMP projects with the goal of enabling the creation and management of NFV services. The unified architecture decomposes platform services into several projects, including the Service Orchestrator (SO) which is responsible for the highest level of orchestration to deliver services.

Declarative Or Imperative

Software IS automation by definition. So when considering a high level automation task like orchestration, the natural inclination is to approach it as a traditional software engineering task. Since the early days of operations automation, scripting has been the workhorse. This approach, writing a sequence of instructions tailored to an automation objective, is the imperative approach.
The declarative, or model-driven approach to automation does not do away with imperative programming, but rather seeks to make explicit the underlying objective of the programming in the form of a model. By expressing the end goal of the automation as a model, the objective of the automation becomes far more comprehensible than reverse engineering code. Another essential ingredient of the declarative approach is an orchestrator. The orchestrator interprets models, and automates the execution of imperative code sequences based on the model structure. The orchestrator can be focused on a particular model and automation target, for example OpenStack HOT/HEAT, or it can be very generic and extensible both in terms of model and target automation platform, for example TOSCA/ARIA. A really great read about the imperative/declarative approaches is available from the University of Stuttgart.

TOSCA Videos for Beginners – Learn TOSCA Today!   WATCH THE VIDEOS

TOSCA Modeling

Topology and Orchestration Specification for Cloud Applications (TOSCA) is focused on defining highly generic models who’s geometry can be interpreted by a TOSCA Orchestrator to perform orchestration tasks. The geometry of a TOSCA model depicts the desired initial state of a desired application topology. The “Cloud” in the specification title, the modeling language is far more generalized, and can model any application architecture, virtual or otherwise.
TOSCA takes an object oriented approach to modeling, including concepts such as types, interfaces, and inheritance. As in object oriented programming, inheritance is useful for describing ‘kind-of’ relationships between types. A type can have static, modeling-time, properties as well as dynamic run-time properties (known as attributes). Types can also implement interfaces, which describe a set of operations. Operations can be implemented by imperative user code. TOSCA provides simple base types from which user defined types can be derived. A simple example of a type definition:

Type definitions are used in topology templates in the form of node templates. An example usage of the above type:

A TOSCA orchestrator, upon encountering the my_server node while installing a topology, would first recognize the normative Standard interface, and then execute each of the lifecycle operations (create,configure,start) in sequence. Multiple types can be combined in a topology by way of relationships, requirements, and capabilities. For example, a node type representing a software component (e.g. database), could declare that it requires my_server via a hosting relationship. This relationship would cause the component to be installed on the compute node. Hierarchies of types are defined to be traversed by the orchestrator to construct deployments.

ONAP From A TOSCA Perspective

ONAP consists of many projects and many services which must be orchestrated to deliver project objectives. At the service orchestration level, there are a few key internal services which must be coordinated to deliver network services to users. Each of these has an API that can be modeled as TOSCA components. Some key projects/services:

• AAI – Active and Available Inventory. A system-scope data store for tracking status and inventory.
• SDNC – Software Defined Networking Controller. SDN allocation and provisioning.
• Multi-VIM – Multi-cloud mediation layer.
• OF – Optimization Framework. Homing and change management
• APPC – VNF Instantiation, configuration and lifecycle management
• DCAE – Data Collection and Events. Instrumentation and messaging.

One way of thinking about TOSCA modeling is in relation to the grammar of the APIs it models. Every API represents consists of nouns (what is being operated on), verbs (the operations), and adjectives (properties). For example, every IAAS compute API has concepts such as servers (noun), cpu and memory (adjectives), and verbs (create, suspend, destroy). As such, each of the ONAP services described above could be described as a set of TOSCA types. To describe a NFV service, a designer could assemble an arrangement/topology of nodes and relationships represent the ONAP infrastructure, along with VNF types and their interconnections.
Such an approach ignores service designer experience and implementation hiding however. A service designer should not be required to understand ONAP infrastructure; a large portion of the design work would involve defining potentially complex relationships between service components and ONAP services. The knowledge barrier and the complexity barrier represent barriers to adoption of ONAP as a platform. A negative side effect of including ONAP services in service models is the explicit binding of service models to ONAP implementation, or even to specific releases of ONAP services. This lack of abstraction and encapsulation is another potential source of frustration, inefficiency, and ultimately the adoption and longer term success of the platform.
So the task of service modeling in ONAP is a balance between power of expression and implementation hiding/abstraction. Implementation in ONAP/SO can be hidden or abstracted in a few ways:

• Normative ONAP TOSCA types
• TOSCA orchestrator custom workflows
• Imperative code (BPMN workflows, adapters)

Service Modeling Approach Breakdown in SO

AAI

AAI interactions in ONAP are ubiquitous. Creating services, networking elements, VNFs, and application components all require creating, deleting or modifying records in AAI. To model AAI as a TOSCA type would require a service designer to define connections between the AAI node and every service element node. This is a component of ONAP that clearly a designer shouldn’t need to deal with. Fortunately, AAI can be hidden in both in ONAP TOSCA types and imperative code. For example, when a service creation request is received by the SO, conventional imperative calls can be made to AAI (from java). Interactions with other ONAP services, for example APPC or Multi-VIM, can be handled by TOSCA type lifecycle operations. The Multi-VIM TOSCA API, for example, defines a Network type. The create lifecycle operation, prior to actually calling the Multi-VIM service, calls AAI and registers the creation attempt using properties attached to the Network node in the TOSCA template.

SDNC/OF

In ONAP, the SDNC and OF services share a common operational concept; they demand a global view of an orchestration in order to produce a solution, either in the networking domain or home/placement of VMs/containers. Both services evaluate TOSCA in order to develop solutions based on policies. TOSCA orchestration is a traversal-oriented process, and yet a service creation request in ONAP must make multiple passes across the entire topology/service template. This architecture lends itself to an imperative solution, where the SDNC and OF services are consulted as a form of pre-processing. The results from the SDNC and OF are then fed as inputs to the service template. The calls to OF and SDNC could be implemented anywhere imperative processing occurs in the SO service instantiation pipeline, including BPMN, adapters, and a custom install workflow for the TOSCA orchestrator.

APPC

In ONAP, APPC is responsible for configuration and management of applications and VNFs. Such a service fits neatly into the TOSCA type paradigm, with APPC API calls forming the implementation in the form of operations. Hosting relationships with Multi-VIM provided hosts are expressible as normative TOSCA relationships (i.e. HostedOn). APPC TOSCA types will express their own requirements and capabilities, as well as custom relationship types for use by service designers.

Multi-VIM

The Multi-VIM project provides a multi-cloud facade to clients in ONAP. The initial released version only supports OpenStack, and can be supported by TOSCA types implemented using the OpenStack APIs. As multi-VIM matures, the TOSCA support will evolve as well. Using Multi-VIM fits naturally into the TOSCA type paradigm, with types representing common OpenStack entities, including instances, networks, ports, public ips, security group, and so on. As Multi-VIM evolves, the TOSCA types that represent it will evolve as well to support advanced capabilities such as cloud and image capability matching.

ARIA and ONAP

The TOSCA orchestrator used in ONAP is ARIA. ARIA is an Apache Software Foundation Project which implements the defacto reference implementation of TOSCA Simple YAML 1.0. The ARIA project provides a Python library that includes a parser, orchestration/execution engine, and CLI. In order to facilitate integration with the SO project, the following items were delivered in the ONAP Amsterdam Release:

• A REST API to enable cross language integration into the SO.
• A java binding for the REST API, also to facilitate integration.
• A lightweight Docker container hosting ARIA.
• A Multi-VIM plugin, based on the Cloudify OpenStack plugin.

For the Beijing release, a full TOSCA/ARIA path is planned, which includes the previously discussed hybrid BPMN/TOSCA service creation path. This effort includes connecting the parts delivered in Amsterdam, but broadens substantially to other ONAP services that will be integrated:

• The development of TOSCA types for OF, APPC, and potentially MultiVIM.
• Service designer (SDC) integration of the TOSCA types.
• SDNC and OF ONAP TOSCA types recognition/coordination.
• SO BPMN/adapter/ARIA coordination/handoff (via TOSCA inputs).
• Python DMaaP API and related APPC TOSCA types.
• ONAP aware ARIA workflows
• DCAE initialization.

Video Presentation

Watch the presentation of TOSCA Service Orchestration in the ONAP Wiki.

ONAP Hackathon and ONAP Day Tel Aviv

We are very proud to bring the ONAP Hackathon and a full ONAP Day to Tel Aviv. The hackathon is taking place Monday, October 16th and the Open Source Networking Day is set for Thursday, October 19th.