...
In the figure above, five participants are shown. A Configuration Perisistence Participant manages Control Loop Elements that interact with the ONAP Configuration Persistence Service to store common data. The DCAE Participant runs Control Loop Elements that manage DCAE microservices. The Kubernetes Participant hosts the Control Loop Elements that are managing the life cycle of microservices in control loops that are in a Kubernetes ecosystem. The Policy Participant handles the Control Loop Elements that interact with the Policy Framework to manage policies for control loops. A Controller Participant such as the CDS Participant runs Control Loop Elements that load metadata and configure controllers so that they can partake in control loops. Any third party Existing System Participant can be developed to run Control Loop Elements that interact with any existing system (such as an operator's analytic, machine learning, or artificial intelligence system) so that those systems can partake in control loops.
4.
...
The diagram below shows the most important Control Loop concepts and how they are related to each other.
| draw.io Diagram | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Non Functional Considerations
...
4.1 Upgrade
Performing a hot upgrade of a Control Loop Instance at run time as well as handling an upgrade of the software in one or more of the participants in an Control Loop is a particularly challenging issue because upgrading must handle the following cases without tearing down the Control Loop:
...
- A Control Loop or Control Loop Element in state RUNNING can be upgraded/downgraded to a different patch level. This means that hot changes that do not impact the structure of a Control Loop or its elements can be executed.
- A Control Loop or Control Loop Element in state PASSIVE can be upgraded/downgraded to a different minor or patch level. This means that structural changes to Control Loop Elements that do not impact the Control Loop as a whole can be executed by taking the control loop to state PASSIVE.
- A Control Loop or Control Loop Element in state UNINITIALIZED can be upgraded/downgraded to a different major/minor/patch level. This means that where the structure of the entire control loop is changed, the control loop must be uninitialized and reinitialized.
- If a Control Loop Element has a minor version change, then its Control Loop Instance must have at least a minor version change.
- If a Control Loop Element has a major version change, then its Control Loop Instance must have a major version change.
...
4.2 Scalability
The system is designed to be inherently scalable. The CLAMP runtime is stateless, all state is preserved in the run time inventory in the database. When the user requests an operation such as an instantiation, activation, passivation, or an uninitialization on a Control Loop Instance, the CLAMP runtime broadcasts the request to participants over DMaaP and saves details of the request to the database. The CLAMP runtime does not directly wait for responses to requests.
...
This approach makes it easy to scale Control Loop life cycle management. As Control Loop Instance counts increase, more than one CLAMP runtime can be deployed and REST/supervision operations on Control Loop Instances can run in parallel. The number of participants can scale because an asynchronous broadcast mechanism is used for runtime-participant communication and there is no direct connection or communication channel between participants and CLAMP runtime servers. Participant state, Control Loop Instance state, and Control Loop Element state is held in the database, so any CLAMP runtime server can handle operations for any participant. Because many participants of a particular type can be deployed and participant instances can load balance control loop element instances for different Control Loop Instances of many types across themselves using a mechanism such as a Kubernetes cluster.
...
5. APIs and Protocols
The APIs and Protocols used by CLAMP for Control Loops are described on the pages below:
- Defining Control Loops in TOSCA for CLAMP
- REST APIs for CLAMP Control Loops
- The CLAMP Control Loop Participant Protocol
...
6. Design and Implementation
The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
...