Table of Contents |
---|
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 end points endpoints is a TOSCA Service/Topology template that defines the new or changed Control Loop Automation Composition Type. The update and delete endpoints take a reference to the Control Loop Automation Composition Type. The incoming TOSCA is verified and checked for referential integrity. OnĀ delete requests, a check is made to ensure that no Control Loop Automation Composition Instances exist for the Control Loop Automation Composition Type to be deleted.
...
Instantiation API
The instantiation API has two functions:
- Creation, Reading, Update, and Deletion of Control Loop Automation Composition Instances.
- Instantiation and lifecycle management of Control Loop 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 Control Loop Automation Composition Instances. The endpoints for create and update take a JSON body that describes the Control Loop Automation Composition Instance. The endpoints for read and delete take a Control Loop an Automation Composition Instance ID to determine which Control Loop Automation Composition Instance to act on. For the delete endpoint, a check is made to ensure that the Control Loop Automation Composition Instance is not instantiated on participants.
A call to the update endpoint for a Control Loop Instance follow an Automation Composition Instance follows the semantics described here: TOSCA Defined Control LoopAutomation Compositions: Architecture and DesignDesign#4.1Upgrade.
...
Instantiation
...
Automation Composition Instance Lifecycle Management
This sub API is used to manage the life cycle of Control Loop Automation Composition Instances. A Control Loop An Automation Composition Instance can be in the states described here: TOSCA Defined Control LoopAutomation Compositions: Architecture and DesignDesign#2.1:ACMInstanceStates. Managing the life cycle of a Control Loop an Automation Composition Instance amounts to steering the Control Loop Automation Composition through its states.
The sub API allows upgrades and downgrades of Control Loop Automation Composition Instances to be pushed to participants following the semantics described here: TOSCA Defined Control LoopAutomation Compositions: Architecture and DesignDesign#4.1Upgrade. When the API is used to update the participants on a Control Loop an Automation Composition Instance, the new/upgraded/downgraded definition of the Control Loop Automation Composition is pushed to the participants. Note that the API asks the participants in a Control Loop 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 REST APIs for CLAMP Control Loops MonitoringAPI.
The sub API also allows a state change of a Control Loop an Automation Composition Instance to be ordered. The required state of the Control Loop Automation Composition Instance is pushed to participants in a Control Loop an Automation Composition Instance using the API. Note that the API asks the participants in a Control Loop 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 REST APIs for CLAMP Control Loops MonitoringAPI.
Note |
---|
The Swagger for the Instantiation Lifecycle Management API will appear here. |
Monitoring API
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.
Pass Through API
Participant Standalone API
Participant Simulator 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.
Pass Through API
This API allows information to be passed to Automation Composition Elements in an Automation Composition.
Note |
---|
The requirements on this API are still under discussion. |
Note |
---|
The Swagger for the Pass Through API will appear here. |
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.
Participant Simulator API
This API allows a Participant Simulator to be started and run for test purposes.
Sirisha Manchikanti please expand this description.