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
This proposal tries to broadly follow the same kind of modeling as already created for DCAE service components and policies as they are treated in onboarding to SDC. There will be some proposals for handling some details differently and they will be added when a detailed proposal is created, probably some time in July. On a high level it is proposed that the onboard flow for control loop resources would be mostly similar and preferably sharing most of the code with generic onboarding of other resources. Things like licensing will inevitably come to matter also for control loop resources as well when commercial AI engines and similar get deployed for control loop purposes.
The real difference to existing models comes to output from SDC, the service CSAR. At the moment the control loop itself is not represented there at all, only some of its parts. DCAE blueprint as a separate artifact is attached and policy types are in the TOSCA model. The core of this proposal is to reify the control loops to become first class TOSCA citizens, topology or node templates, in the service CSAR and its TOSCA model. Conceptually the reasoning for this is that although control loops are used for a secondary purpose compared to xNFs, they still get implemented by LCM of resources on various components of ONAP, external clouds and possibly dedicated external physical systems.
Compared to current state, this pushes the ToscaLab part of translation between TOSCA and Cloudify blueprint and possibly other DCAE-specific formats to DCAE itself. Or possibly the translation could stay in SDC and DCAE-native blueprint included to CSAR, but it would be in addition to TOSCA encoding of the DCAE part. This should not be a big practical issue as the code for this has anyway been written by DCAE until now. Benefit is a more complete, standardized and usable model from SDC.
Example Onboarding of TCA and Design of a Service
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.
The example above shows control loops attached to the service level, but from TOSCA modeling or orchestration point of view it can as well be attached to VNF level, attach it to another control loop or anything as well. Actually figuring out the details of these less familiar cases will probably still take a long time, but having a place in them in the models enables smooth extension roadmap if/when those become valuable enough.