The CLAMP control loop feature has the APIs that are described in the following sections.

Commissioning API

This API is a CRUD API that allows Control Loop Automation Composition Type definitions created in a design environment to be commissioned on the CLAMP runtime. It has endpoints that allow Control Loop Automation Composition Types to be created, read, updated, and deleted.

The body of the create and update endpoints is a TOSCA Service/Topology template that defines the new or changed Automation Composition Type. The update and delete endpoints take a reference to the Automation Composition Type. The incoming TOSCA is verified and checked for referential integrity. On delete requests, a check is made to ensure that no Automation Composition Instances exist for the Automation Composition Type to be deleted.

Image Added

Instantiation API

Monitoring API

Pass Through API

Participant Standalone API

3: APIs and Sequence Diagrams

3.1: Commissioning

Ajay Deep Singh to pad out this section

This section defines Commissioning/CRUD Operations that can be performed on ControlLoops.

A Client, in this case CLAMP, can perform CRUD operations or can commission ControlLoops from DesignTime to RunTime Inventory Database.

DesignTime/RunTime Catalogue/Inventory Database stores ControlLoop definitions, CRUD operations on database supported by REST Endpoints like Get, Delete, Create allowing selection of a particular ControlLoop to be addressed, below sequence diagram will help you understand flow how a client(Clamp) application can initiate Rest call for performing different operations on Database.

API_Gateway Service is for interacting to different database DesignTime/RunTime and should be responsible for responding success or failure status on different operations.

The commissioning of ControlLoops definition from DesignTime Catalogue to RunTime Inventory Database can we achived using the commissioning Rest Endpoint, in this process when a rest request is initiated from a client(Clamp) the API_Gateway Service take cares of fetching ControlLoops metadata from DesignTime and creates in RunTime Inventory Database, Commissioning API ControlLoop Sequence diagram will help you understand the flow.

3.1.1: Commissioning REST API 

3.1.2: Commissioning Sequence Diagrams

GET, DELETE, CREATE API ControlLoop Sequence Diagram

Commission API ControlLoop Sequence Diagram 

3.2: Instantiation

Robertas Rimkus to pad out this section

This section refers to Instantiation of a Commissioned control loop. A client, in this case CLAMP (potentially DCAEMOD, etc in the future) will render the commissioned control loops allowing selection of a particular control loop to be instantiated. User will then provide the configurations needed to instantiate the selected control loop which will be sent onto the CL_Instance_Control Service. The service will then distribute the configurations to DMaaP topic. Participants (agents) will pull the event containing the config and pick out their control loop components to be instantiated and start/set up those particular components. CL_Instance_Control Service will be waiting for a response back from all participants involved in the instantiation of the control loop, in regards to the state of instantiation. In successful response case the service will store the CL Instance LCM (Life Cycle management) data into the runtime DB as well as providing a message back to the client of the successful instantiation. In failure to receive the response case, a timeout will be called, which will result in a teardown event being sent to DMaaP. The participants will then receive the event and proceed to teardown the components that were instantiated or check that they have failed to instantiate in the first place and send a Teardown ACK back to the CL_Instance_Control Service. No CL Instance LCM data will be stored and a message indicating failure to instantiate the CL along side with the error will be sent back to the client (CLAMP).

3.2.1: Instantiation REST API

3.2.2: Instantiation Sequence Diagrams

3.2.3: Instantiation DMaaP API

Initial Thought for an event to be sent from CL_Instance_Control onto DMaaP for Participants to consume. The event would go onto an output topic which the Participants would be polling/subscribed to

e.g url : https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_INSTANCE_CONTROL_OUTPUT

*Preferred solution is to send TOSCA in the body. Meaning we could reuse the parsing code which is already present and provide it to the participant. 

3.2.4: Instantiation Participant API

*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD

3.3: Monitoring

In this case it refers to monitoring the data that the participants will provide to DMaaP. Participants will send events to DMaaP which will be pulled by the CL_Supervision_Service in to the runtime database. Monitoring service provides APIs to display the statistics data from runtime database to the Monitoring GUI. The data provided should include a reference id to the control loops that are instantiated on the participant, as well as the applications that have been instantiated as a part of that control loop for that participant. Data should also include the time that the application has started, state of it (running/terminated) and any other critical information which would help to determine the health of an instantiated control loop and its components. Idea is for the participant to provide events every certain period of time, similar to a health-check, in order to provide consistent monitoring.

3.3.1: Monitoring REST API

3.3.2: Monitoring Sequence Diagrams

3.3.3: Monitoring DMaaP API

Participants will send an event containing monitoring data to a DMaaP topic at a set interval after participant has received an event to instantiate a control loop

e.g url: https://{{ONAPIP}}:{{DMaaPPort}}/events/CL_MONITORING_SERVICE_INPUT

3.3.4: Monitoring Participant API

Presume similar thinking to Instantiation Participant API

*Suggestion was to put JAVA API code in this section for the participant talking to DMaaP. TBD

3.4: Supervision

Supervision is responsible for ensuring that

1. control loops are established once their initiation has been ordered
2. control loops are running correctly once their initiation is completed
3. control loops are correctly removed once their removal has been ordered

3.4.1: Supervision Sequence Diagrams

The instantiation API has two functions:

1. Creation, Reading, Update, and Deletion of Automation Composition Instances.
2. Instantiation and lifecycle management of Automation Composition Instances on participants

The Instantiation API is used by the CLAMP GUI.

Instantiation Automation Composition Instance CRUD

This sub API allows for the creation, read, update, and deletion of Automation Composition Instances. The endpoints for create and update take a JSON body that describes the Automation Composition Instance. The endpoints for read and delete take an Automation Composition Instance ID to determine which Automation Composition Instance to act on. For the delete endpoint, a check is made to ensure that the Automation Composition Instance is not instantiated on participants.

A call to the update endpoint for an Automation Composition Instance follows the semantics described here: TOSCA Defined Automation Compositions: Architecture and Design#4.1Upgrade.

Image Added

Instantiation Automation Composition Instance Lifecycle Management

This sub API is used to manage the life cycle of Automation Composition Instances. An Automation Composition Instance can be in the states described here: TOSCA Defined Automation Compositions: Architecture and Design#2.1:ACMInstanceStates. Managing the life cycle of an Automation Composition Instance amounts to steering the Automation Composition through its states.

The sub API allows upgrades and downgrades of Automation Composition Instances to be pushed to participants following the semantics described here: TOSCA Defined Automation Compositions: Architecture and Design#4.1Upgrade. When the API is used to update the participants on an Automation Composition Instance, the new/upgraded/downgraded definition of the Automation Composition is pushed to the participants. Note that the API asks the participants in an Automation Composition Instance to perform the update, it is the responsibility of the participants to execute the update and report the result using the protocols described here: CLAMP Participants. The progress and result of an update can be monitored using the MonitoringAPI.

The sub API also allows a state change of an Automation Composition Instance to be ordered. The required state of the Automation Composition Instance is pushed to participants in an Automation Composition Instance using the API. Note that the API asks the participants in an Automation Composition Instance to perform the state change, it is the responsibility of the participants to execute the state change and report the result using the protocols described here: CLAMP Participants. The progress and result of a state change can be monitored using the MonitoringAPI.

Monitoring API

The Monitoring API allows the state and statistics of Participants, Automation Composition Instances, and their Automation Composition Elements to be monitored. This API is used by the CLAMP GUI. The API provides filtering so that specific Participants and Automation Composition Instances can be retrieved. In addition, the quantity of statistical information to be returned can be scoped.

Image Added

Pass Through API

This API allows information to be passed to Automation Composition Elements in an Automation Composition.

Participant Standalone API

This API allows a Participant to run in standalone mode and to run standalone Automation Composition Elements.

Kubernetes participant can also be deployed as a standalone application and provides REST endpoints for onboarding helm charts to its local chart storage, installing and uninstalling of helm charts to a Kubernetes cluster. It also allows to configure a remote repository in Kubernetes participant for installing helm charts. User can onboard a helm chart along with the overrides YAML file, the chart gets stored in the local chart directory of Kubernetes participant. The onboarded charts can be installed and uninstalled. The GET API fetches all the available helm charts from the chart storage.

Image Added

Participant Simulator API

This API allows a Participant Simulator to be started and run for test purposes.

Sirisha Manchikanti please expand this description.

Image Added

...