...

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 CLAMP Control Loop Lifecycle Management uses the following system level dialogues

4.1 Commissioning Dialogues

Commissioning dialogues are used to commission and decommission Control Loop Type definitions and to set the values of Common Parameters.

4.1.1 Commissioning a Control Loop Type Definition using the CLAMP GUI

4.1.2 Commissioning a Control Loop Type Definition using SDC

4.1.3 Setting Common Parameters for a Control Loop Type Definition

4.1.3 Commissioning a Control Loop Type Definition on Participants

4.1.5 Decommissioning a Control Loop Type Definition on Participants

This dialogue allows a Control Loop Type Definition to be decomissioned so that it can be deleted or its common parameter values can be altered.

4.1.6 Decommissioning a Control Loop Type Definition in CLAMP

4.1.7 Reading Commissioned Control Loop Type Definitions

...

. Life Cycle Management Operations

...

4.1 Control Loop Version Management

Performing a hot change of a Control Loop Instance at run time is a particularly challenging issue because a change must handle the following cases without tearing down the Control Loop:

...

1. A Control Loop or Control Loop Element in state RUNNING can be changed to a higher patch level or rolled back to a lower patch level. This means that hot changes that do not impact the structure of a Control Loop or its elements can be executed.
2. A Control Loop or Control Loop Element in state PASSIVE can be changed to a higher minor/patch level or rolled back to a lower minor/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.
3. A Control Loop or Control Loop Element in state UNINITIALIZED can be changed to a higher major/minor/patch level or rolled back to a lower 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.
4. If a Control Loop Element has a minor version change, then its Control Loop Instance must have at least a minor version change.
5. 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:

1. System Level Dialogues
2. Defining Control Loops in TOSCA for CLAMP
3. REST APIs for CLAMP Control Loops
4. 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:

...