TOSCA ONAP Service Orchestration

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.

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:

my.server.type:
  derived_from: tosca.nodes.Compute
  properties:
    ssh_public_key_filename:
      type: string
    iaas_url:
      type: string
  attributes:
    ip_address:
      type: string
  interfaces:
    Standard:
      create: scripts/create-instance.sh
      configure: scripts/configure-configure-instance.sh
      start: scripts/start.sh
      stop: scripts/stop.sh
      delete: scripts/delete.sh

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

my_server:
  type: my.server.type
  properties:
    ssh_public_key_filename: /some/path/mykey.pub
    iaas_url: http://somecloud.com/compute

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. There is far more richness in TOSCA modeling, which is beyond the scope of this post.