Under Construction

This page is a high level proposal for modeling control loops. This tries to give an option how to achieve the aims of the Metadata Driven Control Loops as understood by the author.

The Shortest Version

Onboard types (of policy, DCAE service component, related data type) and topology templates (of DCAE service component, possibly policy for more a complex PDP). Design topology templates using those the onboarded material in service context. Control loop templates and lower level templates and types get packaged to service CSAR and distributed similarly as VNFs and other entities. 

TOSCA Modeling

Orchestration

As a control loop is modeled with TOSCA, it can be orchestrated by a TOSCA orchestrator with suitable support for control loop specific node types. It also can and should be included in a common orchestration hierarchy with the rest of the service. This enables also full ONAP service model including control loops, or just the control loop part, to be executed by a third-party orchestrator. This would be great as there are many non-ONAP orchestrators in the field but they could still share ONAP-style modeling. 

In terms of current ONAP architecture this would mean that the whole service can be instantiated using SO API which delegates control loop typed templates to CLAMP which further delegates policies to Policy and dcae entities to DCAE. This would allow fixing the current problem that services and their control loops do not have common LCM, so they need to be instantiated, terminated and everything separately. In this model for example adding a control loop to a running service will still be possible, but it will be done by creating a new version of the service model and upgrading to it.