:maxdepth: 1
clamp/clamp
- clamp/user-guide
- clamp/architecture
controlloop/controlloop
- controlloop/system-level-dialogues
- controlloop/defining-controlloops
- controlloop/controlloop-participant-protocol
- controlloop/controlloop-rest-apis
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (c) 2017-2021 AT&T Intellectual Property. All rights reserved.
+
.. _architecture:
-Policy/Clamp in ONAP Architecture
----------------------------------
+
+Policy/Clamp in the ONAP Architecture
+=====================================
CLAMP platform has been integrated into the Policy framework project, starting as a POC during
Honolulu release and as a official feature with Istanbul release. So CLAMP must be seen now
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright (c) 2017-2021 AT&T Intellectual Property. All rights reserved.
+
+.. _clamp-description-label:
+
+Policy/CLAMP - Design, and Packaging Information
+================================================
+
+This page describes design and packaging information for release planning and delivery.
+
+
+Offered APIs
+------------
+The list of APIs that Policy/CLAMP offers can be found on the following table:
+
+.. |pdf-icon| image:: images/pdf.png
+ :width: 40px
+
+.. |swagger-icon| image:: images/swagger.png
+ :width: 40px
+
+.. |html-icon| image:: images/html.png
+ :width: 40px
+
+.. csv-table::
+ :header: "|Swagger-icon|", "|html-icon|", "|pdf-icon|"
+ :widths: 60,60,60
+
+ "swagger json file", "html doc", "pdf doc"
+ ":download:`link <swagger/swagger.json>`", ":download:`link <swagger/swagger.html>`", ":download:`link <swagger/swagger.pdf>`"
+
+
+Consumed APIs
+-------------
+Policy/CLAMP uses the API's exposed by the following ONAP components:
+
+- SDC : REST based interface exposed by the SDC, Distribution of service to DCAE
+- DCAE: REST based interface exposed by DCAE, Common Controller Framework, DCAE microservices onboarded (TCA, Stringmatch, Holmes (optional))
+- Policy Core: REST based interface, Policy Core engine target both XACML and Drools PDP, Policy Engine trigger operations to App-C/VF-C/SDN-C
+- CDS: REST based interface, to retrieve list of operations/actions with their corresponding payload at runtime for Operational Policies where the field 'actor' is 'CDS'.
+
+Delivery
+--------
+Policy/CLAMP component is composed of a UI layer and a backend layer, each layer having its own container.
+Policy/CLAMP also requires a database instance with 1 DB, it uses MariaDB, which is the same DB as for the core Policy.
+
+.. |clamp-policy-archi| image:: images/clamp-policy_archi.png
+
+|clamp-policy-archi|
+
+Logging & Diagnostic Information
+--------------------------------
+CLAMP uses logback framework to generate logs. The logback.xml file can be found under the **src/main/resources** folder.
+
+With the default log settings, all logs will be generated into console and into root.log file under the CLAMP root folder. The root.log file is not allowed to be appended, thus restarting the CLAMP will result in cleaning of the old log files.
+
+
+.. _index-clamp-installation:
+
+Installation
+------------
+A *docker-compose* example file **extra/docker/clamp/docker-compose.yml** can be found under the **extra/docker/clamp/** folder.
+
+Once the image has been built and is available locally, you can use the `docker-compose up` command to deploy a pre-populated database and a CLAMP instance available on **https://localhost:3000**.
+
+Configuration
+-------------
+.. Where are they provided?
+.. What are parameters and values?
+
+
+Currently, the CLAMP docker images can be deployed with small configuration needs. Though, you might need to make small adjustments to the configuration. As CLAMP is spring based, you can use the SPRING_APPLICATION_JSON environment variable to update its parameters.
+
+.. TODO detail config parameters and the usage
+
+
+There are one datasource for Clamp. By default, it will try to connect to the localhost server using the credentials available in the example SQL files. If you need to change the default database host and/or credentials, you can do it by using the following json as SPRING_APPLICATION_JSON environment variable :
+
+.. code-block:: json
+
+ {
+ "spring.datasource.cldsdb.url": "jdbc:mariadb:sequential://clampdb.{{ include "common.namespace" . }}:3306/cldsdb4?autoReconnect=true&connectTimeout=10000&socketTimeout=10000&retriesAllDown=3",
+ "clamp.config.files.sdcController": "file:/opt/clamp/sdc-controllers-config.json",
+ "clamp.config.dcae.inventory.url": "https://inventory.{{ include "common.namespace" . }}:8080",
+ "clamp.config.dcae.dispatcher.url": "https://deployment-handler.{{ include "common.namespace" . }}:8443",
+ "clamp.config.dcae.deployment.url": "https://deployment-handler.{{ include "common.namespace" . }}:8443",
+ "clamp.config.dcae.deployment.userName": "none",
+ "clamp.config.dcae.deployment.password": "none",
+ "clamp.config.policy.api.url": "https://policy-api.{{ include "common.namespace" . }}:6969",
+ "clamp.config.policy.api.userName": "healthcheck",
+ "clamp.config.policy.api.password": "zb!XztG34",
+ "clamp.config.policy.pap.url": "https://policy-pap.{{ include "common.namespace" . }}:6969",
+ "clamp.config.policy.pap.userName": "healthcheck",
+ "clamp.config.policy.pap.password": "zb!XztG34",
+ "clamp.config.cadi.aafLocateUrl": "https://aaf-locate.{{ include "common.namespace" . }}:8095",
+ "com.att.eelf.logging.path": "/opt/clamp",
+ "com.att.eelf.logging.file": "logback.xml"
+ }
+
+SDC-Controllers config
+----------------------
+This file is a JSON that must be specified to Spring config, here is an example:
+
+.. code-block:: json
+
+ {
+ "sdc-connections":{
+ "sdc-controller1":{
+ "user": "clamp",
+ "consumerGroup": "consumerGroup1",
+ "consumerId": "consumerId1",
+ "environmentName": "AUTO",
+ "sdcAddress": "localhost:8443",
+ "password": "b7acccda32b98c5bb7acccda32b98c5b05D511BD6D93626E90D18E9D24D9B78CD34C7EE8012F0A189A28763E82271E50A5D4EC10C7D93E06E0A2D27CAE66B981",
+ "pollingInterval":30,
+ "pollingTimeout":30,
+ "activateServerTLSAuth":"false",
+ "keyStorePassword":"",
+ "keyStorePath":"",
+ "messageBusAddresses":["dmaaphost.com"]
+ },
+ "sdc-controller2":{
+ "user": "clamp",
+ "consumerGroup": "consumerGroup1",
+ "consumerId": "consumerId1",
+ "environmentName": "AUTO",
+ "sdcAddress": "localhost:8443",
+ "password": "b7acccda32b98c5bb7acccda32b98c5b05D511BD6D93626E90D18E9D24D9B78CD34C7EE8012F0A189A28763E82271E50A5D4EC10C7D93E06E0A2D27CAE66B981",
+ "pollingInterval":30,
+ "pollingTimeout":30,
+ "activateServerTLSAuth":"false",
+ "keyStorePassword":"",
+ "keyStorePath":"",
+ "messageBusAddresses":["dmaaphost.com"]
+ }
+ }
+ }
+
+Multiple controllers can be configured so that Clamp is able to receive the notifications from different SDC servers.
+Each Clamp existing in a cluster should have different consumerGroup and consumerId so that they can each consume the SDC notification.
+The environmentName is normally the Dmaap Topic used by SDC.
+If the sdcAddress is not specified or not available (connection failure) the messageBusAddresses will be used (Dmaap servers)
+
+Administration
+--------------
+
+A user can access Policy/CLAMP UI at the following URL : https://localhost:3000.
+(in this URL 'localhost' must be replaced by the actual host where Policy/CLAMP has been installed if it is not your current localhost)
+For OOM, the URL is https://<host-ip>:30258
+
+.. code-block:: html
+
+ - Without AAF, the credentials are
+ Default username : admin
+ Default password : password
+
+ - With AAF enabled, the certificate p12 must be added to the browser
+ ca path: src/main/resources/clds/aaf/org.onap.clamp.p12, password "China in the Spring"
+ Or get it from this page : https://wiki.onap.org/display/DW/Control+Loop+Flows+and+Models+for+Casablanca
+
+Human Interfaces
+----------------
+.. Basic info on the interface type, ports/protocols provided over, etc.
+
+User Interface - serve to configure control loop
+Policy/CLAMP UI is used to configure the Control Loop designed and distributed by SDC. From that UI it's possible to distribute the configuration policies and control the life-cycle of the DCAE Micro Services.
+Policy/CLAMP UI is also used to manage Policies outside of a Control Loop.
+
+The following actions are done using the UI:
+
+* Design a control loop flow by selecting a predefined template from a list
+ (a template is an orchestration chain of Micro-services, so the template
+ defines how the micro-services of the control loop are chained together)
+
+* Give value to the configuration the parameters of each micro-service of
+ the control loop
+
+* Select the service and VNF(of that service) to which the control loop
+ will be attached
+
+* Configure the operational policy(the actual operation resulting from
+ the control loop)
+
+* Send the “TOSCA” blueprint parameters that will be used by DCAE to start the
+ control loop (The blueprint will be sent first to SDC and SDC will
+ publish it to DCAE)
+
+* Trigger the deployment of the Control loop in DCAE
+
+* Control (start/stop) the operation of the control loop in DCAE
+
+HealthCheck API - serve to verify CLAMP status (see offered API's section)
+* https://<host-ip>:8443/restservices/clds/v1/healthcheck
+This one does not require the certificate
+
+Walk-through can be found here: https://wiki.onap.org/display/DW/CLAMP+videos
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (c) 2017-2021 AT&T Intellectual Property. All rights reserved.
+
.. _clamp-builtin-label:
Policy/CLAMP - Control Loop Automation Management Platform
==========================================================
-.. High level architecture, design, and packaging information for release planning and delivery.
-
-.. include:: architecture.rst
-
-
-Offered APIs
-------------
-The list of APIs that Policy/CLAMP offers can be found on the following table:
-
-.. |pdf-icon| image:: images/pdf.png
- :width: 40px
-
-.. |swagger-icon| image:: images/swagger.png
- :width: 40px
-
-.. |html-icon| image:: images/html.png
- :width: 40px
-
-.. csv-table::
- :header: "|Swagger-icon|", "|html-icon|", "|pdf-icon|"
- :widths: 60,60,60
-
- "swagger json file", "html doc", "pdf doc"
- ":download:`link <swagger/swagger.json>`", ":download:`link <swagger/swagger.html>`", ":download:`link <swagger/swagger.pdf>`"
-
-
-Consumed APIs
--------------
-Policy/CLAMP uses the API's exposed by the following ONAP components:
-
-- SDC : REST based interface exposed by the SDC, Distribution of service to DCAE
-- DCAE: REST based interface exposed by DCAE, Common Controller Framework, DCAE microservices onboarded (TCA, Stringmatch, Holmes (optional))
-- Policy Core: REST based interface, Policy Core engine target both XACML and Drools PDP, Policy Engine trigger operations to App-C/VF-C/SDN-C
-- CDS: REST based interface, to retrieve list of operations/actions with their corresponding payload at runtime for Operational Policies where the field 'actor' is 'CDS'.
-
-Delivery
---------
-Policy/CLAMP component is composed of a UI layer and a backend layer, each layer having its own container.
-Policy/CLAMP also requires a database instance with 1 DB, it uses MariaDB, which is the same DB as for the core Policy.
-
-.. |clamp-policy-archi| image:: images/clamp-policy_archi.png
-
-|clamp-policy-archi|
-
-Logging & Diagnostic Information
---------------------------------
-CLAMP uses logback framework to generate logs. The logback.xml file can be found under the [src/main/resources/ folder](src/main/resources).
-
-With the default log settings, all logs will be generated into console and into root.log file under the CLAMP root folder. The root.log file is not allowed to be appended, thus restarting the CLAMP will result in cleaning of the old log files.
-
-
-.. _index-clamp-installation:
-
-Installation
-------------
-A [docker-compose example file](extra/docker/clamp/docker-compose.yml) can be found under the [extra/docker/clamp/ folder](extra/docker/).
-
-Once the image has been built and is available locally, you can use the `docker-compose up` command to deploy a pre-populated database and a CLAMP instance available on [https://localhost:3000](https://localhost:3000).
-
-Configuration
--------------
-.. Where are they provided?
-.. What are parameters and values?
-
-
-Currently, the CLAMP docker images can be deployed with small configuration needs. Though, you might need to make small adjustments to the configuration. As CLAMP is spring based, you can use the SPRING_APPLICATION_JSON environment variable to update its parameters.
-
-.. TODO detail config parameters and the usage
-
-
-There are one datasource for Clamp. By default, it will try to connect to the localhost server using the credentials available in the example SQL files. If you need to change the default database host and/or credentials, you can do it by using the following json as SPRING_APPLICATION_JSON environment variable :
-
-.. code-block:: json
-
- {
- "spring.datasource.cldsdb.url": "jdbc:mariadb:sequential://clampdb.{{ include "common.namespace" . }}:3306/cldsdb4?autoReconnect=true&connectTimeout=10000&socketTimeout=10000&retriesAllDown=3",
- "clamp.config.files.sdcController": "file:/opt/clamp/sdc-controllers-config.json",
- "clamp.config.dcae.inventory.url": "https://inventory.{{ include "common.namespace" . }}:8080",
- "clamp.config.dcae.dispatcher.url": "https://deployment-handler.{{ include "common.namespace" . }}:8443",
- "clamp.config.dcae.deployment.url": "https://deployment-handler.{{ include "common.namespace" . }}:8443",
- "clamp.config.dcae.deployment.userName": "none",
- "clamp.config.dcae.deployment.password": "none",
- "clamp.config.policy.api.url": "https://policy-api.{{ include "common.namespace" . }}:6969",
- "clamp.config.policy.api.userName": "healthcheck",
- "clamp.config.policy.api.password": "zb!XztG34",
- "clamp.config.policy.pap.url": "https://policy-pap.{{ include "common.namespace" . }}:6969",
- "clamp.config.policy.pap.userName": "healthcheck",
- "clamp.config.policy.pap.password": "zb!XztG34",
- "clamp.config.cadi.aafLocateUrl": "https://aaf-locate.{{ include "common.namespace" . }}:8095",
- "com.att.eelf.logging.path": "/opt/clamp",
- "com.att.eelf.logging.file": "logback.xml"
- }
-
-SDC-Controllers config
-----------------------
-This file is a JSON that must be specified to Spring config, here is an example:
-
-.. code-block:: json
-
- {
- "sdc-connections":{
- "sdc-controller1":{
- "user": "clamp",
- "consumerGroup": "consumerGroup1",
- "consumerId": "consumerId1",
- "environmentName": "AUTO",
- "sdcAddress": "localhost:8443",
- "password": "b7acccda32b98c5bb7acccda32b98c5b05D511BD6D93626E90D18E9D24D9B78CD34C7EE8012F0A189A28763E82271E50A5D4EC10C7D93E06E0A2D27CAE66B981",
- "pollingInterval":30,
- "pollingTimeout":30,
- "activateServerTLSAuth":"false",
- "keyStorePassword":"",
- "keyStorePath":"",
- "messageBusAddresses":["dmaaphost.com"]
- },
- "sdc-controller2":{
- "user": "clamp",
- "consumerGroup": "consumerGroup1",
- "consumerId": "consumerId1",
- "environmentName": "AUTO",
- "sdcAddress": "localhost:8443",
- "password": "b7acccda32b98c5bb7acccda32b98c5b05D511BD6D93626E90D18E9D24D9B78CD34C7EE8012F0A189A28763E82271E50A5D4EC10C7D93E06E0A2D27CAE66B981",
- "pollingInterval":30,
- "pollingTimeout":30,
- "activateServerTLSAuth":"false",
- "keyStorePassword":"",
- "keyStorePath":"",
- "messageBusAddresses":["dmaaphost.com"]
- }
- }
- }
-
-Multiple controllers can be configured so that Clamp is able to receive the notifications from different SDC servers.
-Each Clamp existing in a cluster should have different consumerGroup and consumerId so that they can each consume the SDC notification.
-The environmentName is normally the Dmaap Topic used by SDC.
-If the sdcAddress is not specified or not available (connection failure) the messageBusAddresses will be used (Dmaap servers)
-
-Administration
---------------
-
-A user can access Policy/CLAMP UI at the following URL : https://localhost:3000.
-(in this URL 'localhost' must be replaced by the actual host where Policy/CLAMP has been installed if it is not your current localhost)
-For OOM, the URL is https://<host-ip>:30258
-
-.. code-block:: html
-
- - Without AAF, the credentials are
- Default username : admin
- Default password : password
-
- - With AAF enabled, the certificate p12 must be added to the browser
- ca path: src/main/resources/clds/aaf/org.onap.clamp.p12, password "China in the Spring"
- Or get it from this page : https://wiki.onap.org/display/DW/Control+Loop+Flows+and+Models+for+Casablanca
-
-Human Interfaces
-----------------
-.. Basic info on the interface type, ports/protocols provided over, etc.
-
-User Interface - serve to configure control loop
-Policy/CLAMP UI is used to configure the Control Loop designed and distributed by SDC. From that UI it's possible to distribute the configuration policies and control the life-cycle of the DCAE Micro Services.
-Policy/CLAMP UI is also used to manage Policies outside of a Control Loop.
-
-The following actions are done using the UI:
-
-* Design a control loop flow by selecting a predefined template from a list
- (a template is an orchestration chain of Micro-services, so the template
- defines how the micro-services of the control loop are chained together)
-
-* Give value to the configuration the parameters of each micro-service of
- the control loop
-
-* Select the service and VNF(of that service) to which the control loop
- will be attached
-
-* Configure the operational policy(the actual operation resulting from
- the control loop)
-
-* Send the “TOSCA” blueprint parameters that will be used by DCAE to start the
- control loop (The blueprint will be sent first to SDC and SDC will
- publish it to DCAE)
-
-* Trigger the deployment of the Control loop in DCAE
-
-* Control (start/stop) the operation of the control loop in DCAE
-
-HealthCheck API - serve to verify CLAMP status (see offered API's section)
-* https://<host-ip>:8443/restservices/clds/v1/healthcheck
-This one does not require the certificate
-Walk-through can be found here: https://wiki.onap.org/display/DW/CLAMP+videos
+CLAMP supports the definition, deployment, and life cycle management of control loops.
.. toctree::
- :maxdepth: 1
- :titlesonly:
+ :maxdepth: 2
- CLAMP User Guide <user-guide.rst>
\ No newline at end of file
+ clamp-architecture
+ clamp-description
+ user-guide
\ No newline at end of file
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (c) 2017-2021 AT&T Intellectual Property. All rights reserved.
-Control loop in Policy/CLAMP
-----------------------------
+User Guide: Control loop in Policy/CLAMP
+========================================
+
There are 2 control loop levels in Policy/CLAMP:
- Control loop template: This is created from the DCAE blueprint (designed in the DCAE designer), and distributed by SDC to CLAMP.
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-api-protocol:
+
+CLAMP TOSCA Control Loop APIs and Protocols
+###########################################
+
+The sections below describe the APIs and Protocols used in TOSCA Control Loops.
+
+.. toctree::
+ :maxdepth: 1
+
+ system-level-dialogues
+ controlloop-participant-protocol
+ controlloop-rest-apis
Registration when a participant comes up and update of participant with control loop type
information and common parameter values for its control loop types.
-.. image:: images/clamp-cl-participants/participant-registering.png
+.. image:: ../images/clamp-cl-participants/participant-registering.png
De-registration is executed as a participant goes down.
-.. image:: images/clamp-cl-participants/participant-deregistration.png
+.. image:: ../images/clamp-cl-participants/participant-deregistration.png
Control Loop Priming and De-Priming
Property values for the participants of each participant type mentioned in the Control Loop
Definition are sent to the participants.
-.. image:: images/clamp-cl-participants/controlloop-priming.png
+.. image:: ../images/clamp-cl-participants/controlloop-priming.png
When a control loop is de-primed, the portion of the Control Loop Type Definition and Common
Property values for the participants of each participant type mentioned in the Control Loop
Definition are deleted on participants.
-.. image:: images/clamp-cl-participants/controlloop-depriming.png
+.. image:: ../images/clamp-cl-participants/controlloop-depriming.png
Control Loop Update
Change of control loops uses a semantic versioning approach and follow the semantics described
on the page `4.1 Management of Control Loop Instance Configurations <management-cl-instance-configs>`.
-.. image:: images/clamp-cl-participants/controlloop-update.png
+.. image:: ../images/clamp-cl-participants/controlloop-update.png
The handling of a ControlLoopUpdate message in each participant is as shown below.
-.. image:: images/clamp-cl-participants/controlloop-update-msg.png
+.. image:: ../images/clamp-cl-participants/controlloop-update-msg.png
Control Loop State Change
-------------------------
Loop State Change message matches the Start Phase of the Control Loop Element, the participant processes
the State Change message. Otherwise the participant ignores the message.
-.. image:: images/clamp-cl-participants/controlloop-state-change.png
+.. image:: ../images/clamp-cl-participants/controlloop-state-change.png
The handling of a ControlLoopStateChange message in each participant is as shown below.
-.. image:: images/clamp-cl-participants/controlloop-state-change-msg.png
+.. image:: ../images/clamp-cl-participants/controlloop-state-change-msg.png
Control Loop Monitoring and Reporting
-------------------------------------
Elements, and to gather statistics on control loops. The ParticipantStatus message is sent periodically
by each participant. The reporting interval for sending the message is configurable.
-.. image:: images/clamp-cl-participants/controlloop-monitoring.png
+.. image:: ../images/clamp-cl-participants/controlloop-monitoring.png
Messages
referential integrity. On delete requests, a check is made to ensure that no Control
Loop Instances exist for the Control Loop Type to be deleted.
-:download:`Download Policy Control Loop Commissioning API Swagger <swagger/controlloop-comissioning.json.json>`
+:download:`Download Policy Control Loop Commissioning API Swagger <swagger/controlloop-comissioning.json>`
.. swaggerv2doc:: swagger/controlloop-comissioning.json
future releases of the system will describe how the Design Time functionality interacts
with the Runtime commissioning API.
-.. image:: images/system-dialogues/comissioning-clamp-gui.png
+.. image:: ../images/system-dialogues/comissioning-clamp-gui.png
1.2 Commissioning a Control Loop Type Definition using SDC
----------------------------------------------------------
-.. image:: images/system-dialogues/comissioning-sdc.png
+.. image:: ../images/system-dialogues/comissioning-sdc.png
1.3 Setting Common Properties for a Control Loop Type Definition
----------------------------------------------------------------
This dialogue sets the values of common properties. The values of the common properties
may be set, updated, or deleted at will, as this dialogue saves the properties to the
database but does not send the definitions or properties to the participants. However,
-once a Control Loop Type Definition and its properties are primed (See :ref:`Section 1.4
-<_priming-cl-label>`), the properties cannot be changed until the control loop type
+once a Control Loop Type Definition and its properties are primed
+(See :ref:`Section 1.4 <priming-cl-label>`), the properties cannot be changed until the control loop type
definition is de-primed (See :ref:`Section 1.5 <depriming-cl-label>`).
-.. image:: images/system-dialogues/common-properties-type-definition.png
+.. image:: ../images/system-dialogues/common-properties-type-definition.png
.. _priming-cl-label:
to participants. Once a Control Loop Type definition is primed, its property values
can on longer be changed until it is de-primed.
-.. image:: images/system-dialogues/priming-cl-type-definition.png
+.. image:: ../images/system-dialogues/priming-cl-type-definition.png
.. _depriming-cl-label:
This dialogue allows a Control Loop Type Definition to be de-primed so that it can be
deleted or its common parameter values can be altered.
-.. image:: images/system-dialogues/depriming-cl-type-definition.png
+.. image:: ../images/system-dialogues/depriming-cl-type-definition.png
1.6 Decommissioning a Control Loop Type Definition in CLAMP
-----------------------------------------------------------
-.. image:: images/system-dialogues/decommission-cl-type-definition.png
+.. image:: ../images/system-dialogues/decommission-cl-type-definition.png
1.7 Reading Commissioned Control Loop Type Definitions
------------------------------------------------------
-.. image:: images/system-dialogues/read-commision-cl-type-definition.png
+.. image:: ../images/system-dialogues/read-commision-cl-type-definition.png
2. Instantiation Dialogues
2.1 Creating a Control Loop Instance
------------------------------------
-.. image:: images/system-dialogues/create-cl-instance.png
+.. image:: ../images/system-dialogues/create-cl-instance.png
.. note::
This dialogue creates the Control Loop Instance in the Instantiated Control Loop Inventory.
2.2 Updating Instance Specific Parameters on a Control Loop Instance
--------------------------------------------------------------------
-.. image:: images/system-dialogues/update-instance-params-cl.png
+.. image:: ../images/system-dialogues/update-instance-params-cl.png
.. _updating-cl-instance-config:
2.3 Updating a Control Loop Instance with a Configuration on Participants
-------------------------------------------------------------------------
-.. image:: images/system-dialogues/update-cl-instance-config-participants.png
+.. image:: ../images/system-dialogues/update-cl-instance-config-participants.png
.. _changing-cl-instance-state:
2.4 Changing the state of a Control Loop Instance on Participants
-----------------------------------------------------------------
-.. image:: images/system-dialogues/change-cl-instance-state-participants.png
+.. image:: ../images/system-dialogues/change-cl-instance-state-participants.png
2.5 De-instantiating a Control Loop Instance from Participants
--------------------------------------------------------------
-.. image:: images/system-dialogues/deinstantiate-cl-from-participants.png
+.. image:: ../images/system-dialogues/deinstantiate-cl-from-participants.png
2.6 Deleting a Control Loop Instance
------------------------------------
-.. image:: images/system-dialogues/delete-cl-instance.png
+.. image:: ../images/system-dialogues/delete-cl-instance.png
2.7 Reading Control Loop Instances
----------------------------------
-.. image:: images/system-dialogues/read-cl-instance.png
+.. image:: ../images/system-dialogues/read-cl-instance.png
1. Monitoring Dialogues
3.1 Reporting of Monitoring Information and Statistics by Participants
----------------------------------------------------------------------
-.. image:: images/system-dialogues/monitoring-by-participants.png
+.. image:: ../images/system-dialogues/monitoring-by-participants.png
3.2 Viewing of Monitoring Information
-------------------------------------
-.. image:: images/system-dialogues/view-monitoring-info.png
+.. image:: ../images/system-dialogues/view-monitoring-info.png
3.2 Viewing of Statistics
-------------------------
-.. image:: images/system-dialogues/view-statistics.png
+.. image:: ../images/system-dialogues/view-statistics.png
3.3 Statistics Housekeeping
---------------------------
-.. image:: images/system-dialogues/statistics-housekeeping.png
+.. image:: ../images/system-dialogues/statistics-housekeeping.png
4. Supervision Dialogues
4.1 Supervise Participants
--------------------------
-.. image:: images/system-dialogues/supervise-participants.png
+.. image:: ../images/system-dialogues/supervise-participants.png
4.2 Supervise Control Loops
---------------------------
-.. image:: images/system-dialogues/supervise-controlloops.png
+.. image:: ../images/system-dialogues/supervise-controlloops.png
End of Document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop_architecture-label:
+
+TOSCA Defined Control Loops: Architecture and Design
+####################################################
+
+
+.. contents::
+ :depth: 4
+
+The idea of using control loops to automatically (or autonomously) perform network management
+has been the subject of much research in the Network Management research community, see
+:download:`this paper <files/ControlLoops.pdf>` for some background. However, it is only with
+the advent of ONAP that we have a platform that supports control loops for network management.
+Before ONAP, Control Loops have been implemented by hard-coding components together and hard
+coding logic into components. ONAP has taken a step forward towards automatic implementation
+of Control Loops by allowing parameterization of Control Loops that work on the premise that
+the Control Loops use a set of analytic, policy, and control components connected together in
+set ways.
+
+The goal of the work is to extend and enhance the current ONAP Control Loop support to provide
+a complete open-source framework for Control Loops. This will enhance the current support to
+provide TOSCA based Control Loop definition and development, commissioning and run-time management.
+The participants that comprise a Control Loop and the metadata needed to link the participants
+together to create a Control Loop are specified in a standardized way using the `OASIS TOSCA
+modelling language <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/>`_. The TOSCA
+description is then used to commission, instantiate, and manage the Control Loops in the run
+time system.
+
+.. image:: images/01-controlloop-overview.png
+
+1 Terminology
+=============
+
+This section describes the terminology used in the system.
+
+1.1 Control Loop Terminology
+----------------------------
+
+**Control Loop Type:** A definition of a Control Loop in the TOSCA language. This definition describes
+a certain type of a control loop. The life cycle of instances of a Control Loop Type are managed
+by CLAMP.
+
+**Control Loop Instance:** An instance of a Control Loop Type. The life cycle of a Control Loop
+Instance is managed by CLAMP. A Control Loop Instance is a set of executing elements on which
+Life Cycle Management (LCM) is executed collectively. For example, a set of microservices may be
+spawned and executed together to deliver a service. This collection of services is a control loop.
+
+**Control Loop Element Type:** A definition of a Control Loop Element in the TOSCA language. This
+definition describes a certain type of Control Loop Element for a control loop in a Control
+Loop Type.
+
+**Control Loop Element Instance:** A single entity executing on a participant, with its Life Cycle
+being managed as part of the overall control loop. For example, a single microservice that is
+executing as one microservice in a service.
+
+**CLAMP Control Loop Runtime:** The CLAMP server that holds Control Loop Type definitions and manages
+the life cycle of Control Loop Instances and their Control Loop Elements in cooperation with
+participants.
+
+
+1.2 Participant Terminology
+---------------------------
+
+**Participant Type:** Definition of a type of system or framework that can take part in control
+loops and a definition of the capabilities of that participant type. A participant advertises
+its type to the CLAMP Control Loop Runtime.
+
+**Participant:** A system or framework that takes part in control loops by executing Control Loop
+Elements in cooperation with the CLAMP Control Loop Runtime. A participant chooses to partake
+in control loops, to manage Control Loop Elements for CLAMP, and to receive, send and act on
+LCM messages for the CLAMP runtime.
+
+1.3 Terminology for Properties
+------------------------------
+
+**Common Properties:** Properties that apply to all Control Loop Instances of a certain Control
+Loop Type and are specified when a Control Loop Type is commissioned.
+
+**Instance Specific Properties:** Properties that must be specified for each Control Loop Instance
+and are specified when a Control Loop Instance is Initialized.
+
+1.4 Concepts and their relationships
+------------------------------------
+
+The UML diagram below shows the concepts described in the terminology sections above and how
+they are interrelated.
+
+.. image:: images/02-controlloop-concepts.png
+
+The Control Loop Definition concepts describe the types of things that are in the system. These
+concepts are defined at design time and are passed to the runtime in a TOSCA document. The
+concepts in the Control Loop Runtime are created by the runtime part of the system using the
+definitions created at design time.
+
+.. _controlloop-capabilities:
+
+2 Capabilities
+==============
+
+We consider the capabilities of Control Loops at Design Time and Run Time.
+
+At Design Time, three capabilities are supported:
+
+#. **Control Loop Element Definition Specification.** This capability allows users to define Control
+ Loop Element Types and the metadata that can be used on and configured on a Control Loop Element
+ Type. Users also define the Participant Type that will run the Control Loop Element when it is
+ taking part in in a control loop. The post condition of an execution of this capability is that
+ metadata for a Control Loop Element Type is defined in the Control Loop Design Time Catalogue.
+
+#. **Control Loop Element Definition Onboarding.** This capability allows external users and systems
+ (such as SDC or DCAE-MOD) to define the metadata that can be used on and configured on a Control
+ Loop Element Type and to define the Participant Type that will run the Control Loop Element when
+ it is taking part in in a control loop. The post condition of an execution of this capability
+ is that metadata for a Control Loop Element Type is defined in the Control Loop Design Time
+ Catalogue.
+
+#. **Control Loop Type Definition.** This capability allows users and other systems to create Control
+ Loop Type definitions by specifying a set of Control Loop Element Definitions from those that
+ are available in the Control Loop Design Time Catalogue. These Control Loop Elements will
+ work together to form Control Loops. In an execution of this capability, a user specifies the
+ metadata for the Control Loop and specifies the set of Control Loop Elements and their Participant
+ Types. The user also selects the correct metadata sets for each participant in the Control Loop
+ Type and defines the overall Control Loop Type metadata. The user also specifies the Common
+ Property Types that apply to all instances of a control loop type and the Instance Specific
+ Property Types that apply to individual instances of a Control Loop Type. The post condition for
+ an execution of this capability is a Control Loop definition in TOSCA stored in the Control Loop
+ Design Time Catalogue.
+
+.. note::
+ Once a Control Loop Definition is commissioned to the Control Loop Runtime and has been
+ stored in the Run Time Inventory, it cannot be further edited unless it is decommissioned.
+
+
+At Run Time, the following participant related capabilities are supported:
+
+#. **System Pre-Configuration.** This capability allows participants to register and deregister
+ with CLAMP. Participants explicitly register with CLAMP when they start. Control Loop Priming
+ is performed on each participant once it registers. The post condition for an execution of this
+ capability is that a participant becomes available (registration) or is no longer available
+ (deregistration) for participation in a control loop.
+
+#. **Control Loop Priming on Participants.** A participant is primed to support a Control Loop Type.
+ Priming a participant means that the definition of a control loop and the values of Common
+ Property Types that apply to all instances of a control loop type on a participant are sent
+ to a participant. The participant can then take whatever actions it need to do to support
+ the control loop type in question. Control Loop Priming takes place at participant
+ registration and at Control Loop Commissioning. The post condition for an execution of this
+ capability is that all participants in this control loop type are commissioned, that is they
+ are prepared to run instances of their Control Loop Element types.
+
+
+At Run Time, the following Control Loop Life Cycle management capabilities are supported:
+
+#. **Control Loop Commissioning:** This capability allows version controlled Control Loop Type
+ definitions to be taken from the Control Loop Design Time Catalogue and be placed in the
+ Commissioned Control Loop Inventory. It also allows the values of Common Property Types
+ that apply to all instances of a Control Loop Type to be set. Further, the Control Loop
+ Type is primed on all concerned participants. The post condition for an execution of this
+ capability is that the Control Loop Type definition is in the Commissioned Control Loop
+ Inventory and the Control Loop Type is primed on concerned participants.
+
+#. **Control Loop Instance Life Cycle Management:** This capability allows a Control Loop
+ Instance to have its life cycle managed.
+
+ #. **Control Loop Instance Creation:** This capability allows a Control Loop Instance to be
+ created. The Control Loop Type definition is read from the Commissioned Control Loop
+ Inventory and values are assigned to the Instance Specific Property Types defined for
+ instances of the Control Loop Type in the same manner as the existing CLAMP client does.
+ A Control Loop Instance that has been created but has not yet been instantiated on
+ participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type
+ values can be revised and updated as often as the user requires. The post condition for an
+ execution of this capability is that the Control Loop instance is created in the
+ Instantiated Control Loop Inventory but has not been instantiated on Participants.
+
+ #. **Control Loop Instance Update on Participants:** Once the user is happy with the property
+ values, the Control Loop Instance is updated on participants and the Control Loop Elements
+ for this Control Loop Instance are initialized or updated by participants using the control
+ loop metadata. The post condition for an execution of this capability is that the Control
+ Loop instance is updated on Participants.
+
+ #. **Control Loop State Change:** The user can now order the participants to change the state
+ of the Control Loop Instance. If the Control Loop is set to state RUNNING, each participant
+ begins accepting and processing control loop events and the Control Loop Instance is set
+ to state RUNNING in the Instantiated Control Loop inventory. The post condition for an
+ execution of this capability is that the Control Loop instance state is changed on
+ participants.
+
+ #. **Control Loop Instance Monitoring:** This capability allows Control Loop Instances to be
+ monitored. Users can check the status of Participants, Control Loop Instances, and Control
+ Loop Elements. Participants report their overall status and the status of Control Loop
+ Elements they are running periodically to CLAMP. Clamp aggregates these status reports
+ into an aggregated Control Loop Instance status record, which is available for monitoring.
+ The post condition for an execution of this capability is that Control Loop Instances are
+ being monitored.
+
+ #. **Control Loop Instance Supervision:** This capability allows Control Loop Instances to be
+ supervised. The CLAMP runtime expects participants to report on Control Loop Elements
+ periodically. The CLAMP runtime checks that periodic reports are received and that each
+ Control Loop Element is in the state it should be in. If reports are missed or if a
+ Control Loop Element is in an incorrect state, remedial action is taken and notifications
+ are issued. The post condition for an execution of this capability is that Control Loop
+ Instances are being supervised by the CLAMP runtime.
+
+ #. **Control Loop Instance Removal from Participants:** A user can order the removal of a Control
+ Loop Instance from participants. The post condition for an execution of this capability is
+ that the Control Loop instance is removed from Participants.
+
+ #. **Control Loop Instance Deletion:** A user can order the removal of a Control Loop Instance
+ from the CLAMP runtime. Control Loop Instances that are instantiated on participants cannot
+ be removed from the CLAMP runtime. The post condition for an execution of this capability
+ is that the Control Loop instance is removed from Instantiated Control Loop Inventory.
+
+#. **Control Loop Decommissioning:** This capability allows version controlled Control Loop Type
+ definitions to be removed from the Commissioned Control Loop Inventory. A Control Loop
+ Definition that has instances in the Instantiated Control Loop Inventory cannot be removed.
+ The post condition for an execution of this capability is that the Control Loop Type
+ definition removed from the Commissioned Control Loop Inventory.
+
+.. note::
+ The system dialogues for run time capabilities are described in detail on the
+ :ref:`System Level Dialogues <system-level-label>` page.
+
+.. _controlloop-instance-states:
+
+2.1 Control Loop Instance States
+--------------------------------
+
+When a control loop definition has been commissioned, instances of the control loop can be
+created, updated, and deleted. The system manages the lifecycle of control loops and control
+loop elements following the state transition diagram below.
+
+.. image:: images/03-controlloop-instance-states.png
+
+3 Overall Target Architecture
+=============================
+
+The diagram below shows an overview of the architecture of TOSCA based Control Loop
+Management in CLAMP.
+
+.. image:: images/04-overview.png
+
+Following the ONAP Reference Architecture, the architecture has a Design Time part and
+a Runtime part.
+
+The Design Time part of the architecture allows a user to specify metadata for participants.
+It also allows users to compose control loops. The Design Time Catalogue contains the metadata
+primitives and control loop definition primitives for composition of control loops. As shown
+in the figure above, the Design Time component provides a system where Control Loops can be
+designed and defined in metadata. This means that a Control Loop can have any arbitrary
+structure and the Control Loop developers can use whatever analytic, policy, or control
+participants they like to implement their Control Loop. At composition time, the user
+parameterises the Control Loop and stores it in the design time catalogue. This catalogue
+contains the primitive metadata for any participants that can be used to compose a Control
+Loop. A Control Loop SDK is used to compose a Control Loop by aggregating the metadata for
+the participants chosen to be used in a Control Loop and by constructing the references between
+the participants. The architecture of the Control Loop Design Time part will be elaborated in
+future releases.
+
+Composed Control Loops are commissioned on the run time part of the system, where they are
+stored in the Commissioned Control Loop inventory and are available for instantiation. The
+Commissioning component provides a CRUD REST interface for Control Loop Types, and implements
+CRUD of Control Loop Types. Commissioning also implements validation and persistence of incoming
+Control Loop Types. It also guarantees the integrity of updates and deletions of Control Loop
+Types, such as performing updates in accordance with semantic versioning rules and ensuring that
+deletions are not allowed on Control Loop Types that have instances defined.
+
+The Instantiation component manages the Life Cycle Management of Control Loop Instances and
+their Control Loop Elements. It publishes a REST interface that is used to create Control Loop
+Instances and set values for Common and Instance Specific properties. This REST interface is
+public and is used by the CLAMP GUI. It may also be used by any other client via the public
+REST interface. the REST interface also allows the state of Control Loop Instances to be changed.
+A user can change the state of Control Loop Instances as described in the state transition
+diagram shown in section 2 above. The Instantiation component issues update and state change
+messages via DMaaP to participants so that they can update and manage the state of the Control
+Loop Elements they are responsible for. The Instantiation component also implements persistence
+of Control Loop Instances, control loop elements, and their state changes.
+
+The Monitoring component reads updates sent by participants. Participants report on the
+state of their Control Loop Elements periodically and in response to a message they have
+received from the Instantiation component. The Monitoring component reads the contents of
+the participant messages and persists their state updates and statistics records. It also
+publishes a REST interface that publishes the current state of all Participants, Control
+Loop Instances and their Control Loop Elements, as well as publishing Participant and
+Control Loop statistics.
+
+The Supervision component is responsible for checking that Control Loop Instances are correctly
+instantiated and are in the correct state (UNINITIALIZED/READY/RUNNING). It also handles
+timeouts and on state changes to Control Loop Instances, and retries and rolls back state
+changes where state changes failed.
+
+A Participant is an executing component that partakes in control loops. More explicitly, a
+Participant is something that implements the Participant Instantiation and Participant
+Monitoring messaging protocol over DMaaP for Life Cycle management of Control Loop Elements.
+A Participant runs Control Loop Elements and manages and reports on their life cycle
+following the instructions it gets from the CLAMP runtime in messages delivered over DMaaP.
+
+In the figure above, five participants are shown. A Configuration Persistence Participant
+manages Control Loop Elements that interact with the `ONAP Configuration Persistence Service
+<https://docs.onap.org/projects/onap-cps/en/latest/overview.html>`_
+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. Other Considerations
+=======================
+
+.. _management-cl-instance-configs:
+
+4.1 Management of Control Loop Instance Configurations
+------------------------------------------------------
+
+In order to keep management of versions of the configuration of control loop instances
+straightforward and easy to implement, the following version management scheme using
+semantic versioning is implemented. Each configuration of a Control Loop Instance and
+configuration of a Control Loop Element has a semantic version with 3 digits indicating
+the **major.minor.patch** number of the version.
+
+.. note::
+ A **configuration** means a full set of parameter values for a Control Loop Instance.
+
+.. image:: images/05-upgrade-states.png
+
+Change constraints:
+
+#. 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.
+
+#. 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**.
+
+#. 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.
+
+#. 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 Instantiated Control Loop 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.
+
+When a request is broadcast on DMaaP, the request is asynchronously picked up by participants
+of the types required for the Control Loop Instance and those participants manage the life
+cycle of its control loop elements. Periodically, each participant reports back on the status
+of operations it has picked up for the Control Loop Elements it controls, together with
+statistics on the Control Loop Elements over DMaaP. On reception of these participant messages,
+the CLAMP runtime stores this information to its database.
+
+The participant to use on a control loop can be selected from the registered participants
+in either of two ways:
+
+**Runtime-side Selection:** The CLAMP runtime selects a suitable participant from the list of
+participants and sends the participant ID that should be used in the Participant Update message.
+In this case, the CLAMP runtime decides on which participant will run the Control Loop Element
+based on a suitable algorithm. Algorithms could be round robin based or load based.
+
+**Participant-side Selection:** The CLAMP runtime sends a list of Participant IDs that may be used
+in the Participant Update message. In this case, the candidate participants decide among
+themselves which participant should host the Control Loop Element.
+
+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.
+
+
+4.3 Sandboxing and API Gateway Support
+--------------------------------------
+
+At runtime, interaction between ONAP platform services and application microservices are
+relatively unconstrained, so interactions between Control Loop Elements for a given Control
+Loop Instance remain relatively unconstrained. A
+`proposal to support access-controlled access to and between ONAP services
+<https://wiki.onap.org/pages/viewpage.action?pageId=103417456>`_
+will improve this. This can be complemented by intercepting and controlling services
+accesses between Control Loop Elements for Control Loop Instances for some/all Control
+Loop types.
+
+API gateways such as `Kong <https://konghq.com/kong/>`_ have emerged as a useful technology
+for exposing and controlling service endpoint access for applications and services. When a
+Control Loop Type is onboarded, or when Control Loop Instances are created in the Participants,
+CLAMP can configure service endpoints between Control Loop Elements to redirect through an
+API Gateway.
+
+Authentication and access-control rules can then be dynamically configured at the API gateway
+to support constrained access between Control Loop Elements and Control Loop Instances.
+
+The diagram below shows the approach for configuring API Gateway access at Control Loop
+Instance and Control Loop Element level.
+
+.. image:: images/06-api-gateway-sandbox.png
+
+At design time, the Control Loop type definition specifies the type of API gateway configuration
+that should be supported at Control Loop and Control Loop Element levels.
+
+At runtime, the CLAMP can configure the API gateway to enable (or deny) interactions between
+Control Loop Instances and individually for each Control Loop Element. All service-level
+interactions in/out of a Control Loop Element, except that to/from the API Gateway, can be
+blocked by networking policies, thus sandboxing a Control Loop Element and an entire Control
+Loop Instance if desired. Therefore, a Control Loop Element will only have access to the APIs
+that are configured and enabled for the Control Loop Element/Instance in the API gateway.
+
+For some Control Loop Element Types the Participant can assist with service endpoint
+reconfiguration, service request/response redirection to/from the API Gateway, or
+annotation of requests/responses.
+
+Once the Control Loop instance is instantiated on participants, the participants configure
+the API gateway with the Control Loop Instance level configuration and with the specific
+configuration for their Control Loop Element.
+
+Monitoring and logging of the use of the API gateway may also be provided. Information and
+statistics on API gateway use can be read from the API gateway and passed back in monitoring
+messages to the CLAMP runtime.
+
+Additional isolation and execution-environment sandboxing can be supported depending on the
+Control Loop Element Type. For example: ONAP policies for given Control Loop Instances/Types
+can be executed in a dedicated PDP engine instances; DCAE or K8S-hosted services can executed
+in isolated namespaces or in dedicated workers/clusters; etc..
+
+
+5 APIs and Protocols
+====================
+
+The APIs and Protocols used by CLAMP for Control Loops are described on the pages below:
+
+#. :ref:`System Level Dialogues <system-level-label>`
+#. :ref:`The CLAMP Control Loop Participant Protocol <controlloop-participant-protocol-label>`
+#. :ref:`REST APIs for CLAMP Control Loops <controlloop-rest-apis-label>`
+
+
+6 Design and Implementation
+===========================
+
+The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
+
+#. :ref:`The CLAMP Control Loop Runtime Server <clamp-controlloop-runtime>`
+#. :ref:`CLAMP Control Loop Participants <clamp-controlloop-participants>`
+#. :ref:`Managing Control Loops using The CLAMP GUI <clamp-gui-controlloop>`
+
+End of Document
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-builtin-label:
+.. _clamp-controlloop-label:
CLAMP Metadata Control Loop Automation Management using TOSCA
#############################################################
+CLAMP supports the definition, deployment, and life cycle management of control loops using Metadata described in TOSCA.
-.. contents::
- :depth: 4
+.. toctree::
+ :maxdepth: 2
-The idea of using control loops to automatically (or autonomously) perform network management
-has been the subject of much research in the Network Management research community, see
-:download:`this paper <files/ControlLoops.pdf>` for some background. However, it is only with
-the advent of ONAP that we have a platform that supports control loops for network management.
-Before ONAP, Control Loops have been implemented by hard-coding components together and hard
-coding logic into components. ONAP has taken a step forward towards automatic implementation
-of Control Loops by allowing parameterization of Control Loops that work on the premise that
-the Control Loops use a set of analytic, policy, and control components connected together in
-set ways.
-
-The goal of the work is to extend and enhance the current ONAP Control Loop support to provide
-a complete open-source framework for Control Loops. This will enhance the current support to
-provide TOSCA based Control Loop definition and development, commissioning and run-time management.
-The participants that comprise a Control Loop and the metadata needed to link the participants
-together to create a Control Loop are specified in a standardized way using the `OASIS TOSCA
-modelling language <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/>`_. The TOSCA
-description is then used to commission, instantiate, and manage the Control Loops in the run
-time system.
-
-.. image:: images/01-controlloop-overview.png
-
-1 Terminology
-=============
-
-This section describes the terminology used in the system.
-
-1.1 Control Loop Terminology
-----------------------------
-
-**Control Loop Type:** A definition of a Control Loop in the TOSCA language. This definition describes
-a certain type of a control loop. The life cycle of instances of a Control Loop Type are managed
-by CLAMP.
-
-**Control Loop Instance:** An instance of a Control Loop Type. The life cycle of a Control Loop
-Instance is managed by CLAMP. A Control Loop Instance is a set of executing elements on which
-Life Cycle Management (LCM) is executed collectively. For example, a set of microservices may be
-spawned and executed together to deliver a service. This collection of services is a control loop.
-
-**Control Loop Element Type:** A definition of a Control Loop Element in the TOSCA language. This
-definition describes a certain type of Control Loop Element for a control loop in a Control
-Loop Type.
-
-**Control Loop Element Instance:** A single entity executing on a participant, with its Life Cycle
-being managed as part of the overall control loop. For example, a single microservice that is
-executing as one microservice in a service.
-
-**CLAMP Control Loop Runtime:** The CLAMP server that holds Control Loop Type definitions and manages
-the life cycle of Control Loop Instances and their Control Loop Elements in cooperation with
-participants.
-
-
-1.2 Participant Terminology
----------------------------
-
-**Participant Type:** Definition of a type of system or framework that can take part in control
-loops and a definition of the capabilities of that participant type. A participant advertises
-its type to the CLAMP Control Loop Runtime.
-
-**Participant:** A system or framework that takes part in control loops by executing Control Loop
-Elements in cooperation with the CLAMP Control Loop Runtime. A participant chooses to partake
-in control loops, to manage Control Loop Elements for CLAMP, and to receive, send and act on
-LCM messages for the CLAMP runtime.
-
-1.3 Terminology for Properties
-------------------------------
-
-**Common Properties:** Properties that apply to all Control Loop Instances of a certain Control
-Loop Type and are specified when a Control Loop Type is commissioned.
-
-**Instance Specific Properties:** Properties that must be specified for each Control Loop Instance
-and are specified when a Control Loop Instance is Initialized.
-
-1.4 Concepts and their relationships
-------------------------------------
-
-The UML diagram below shows the concepts described in the terminology sections above and how
-they are interrelated.
-
-.. image:: images/02-controlloop-concepts.png
-
-The Control Loop Definition concepts describe the types of things that are in the system. These
-concepts are defined at design time and are passed to the runtime in a TOSCA document. The
-concepts in the Control Loop Runtime are created by the runtime part of the system using the
-definitions created at design time.
-
-.. _controlloop-capabilities:
-
-2 Capabilities
-==============
-
-We consider the capabilities of Control Loops at Design Time and Run Time.
-
-At Design Time, three capabilities are supported:
-
-#. **Control Loop Element Definition Specification.** This capability allows users to define Control
- Loop Element Types and the metadata that can be used on and configured on a Control Loop Element
- Type. Users also define the Participant Type that will run the Control Loop Element when it is
- taking part in in a control loop. The post condition of an execution of this capability is that
- metadata for a Control Loop Element Type is defined in the Control Loop Design Time Catalogue.
-
-#. **Control Loop Element Definition Onboarding.** This capability allows external users and systems
- (such as SDC or DCAE-MOD) to define the metadata that can be used on and configured on a Control
- Loop Element Type and to define the Participant Type that will run the Control Loop Element when
- it is taking part in in a control loop. The post condition of an execution of this capability
- is that metadata for a Control Loop Element Type is defined in the Control Loop Design Time
- Catalogue.
-
-#. **Control Loop Type Definition.** This capability allows users and other systems to create Control
- Loop Type definitions by specifying a set of Control Loop Element Definitions from those that
- are available in the Control Loop Design Time Catalogue. These Control Loop Elements will
- work together to form Control Loops. In an execution of this capability, a user specifies the
- metadata for the Control Loop and specifies the set of Control Loop Elements and their Participant
- Types. The user also selects the correct metadata sets for each participant in the Control Loop
- Type and defines the overall Control Loop Type metadata. The user also specifies the Common
- Property Types that apply to all instances of a control loop type and the Instance Specific
- Property Types that apply to individual instances of a Control Loop Type. The post condition for
- an execution of this capability is a Control Loop definition in TOSCA stored in the Control Loop
- Design Time Catalogue.
-
-.. note::
- Once a Control Loop Definition is commissioned to the Control Loop Runtime and has been
- stored in the Run Time Inventory, it cannot be further edited unless it is decommissioned.
-
-
-At Run Time, the following participant related capabilities are supported:
-
-#. **System Pre-Configuration.** This capability allows participants to register and deregister
- with CLAMP. Participants explicitly register with CLAMP when they start. Control Loop Priming
- is performed on each participant once it registers. The post condition for an execution of this
- capability is that a participant becomes available (registration) or is no longer available
- (deregistration) for participation in a control loop.
-
-#. **Control Loop Priming on Participants.** A participant is primed to support a Control Loop Type.
- Priming a participant means that the definition of a control loop and the values of Common
- Property Types that apply to all instances of a control loop type on a participant are sent
- to a participant. The participant can then take whatever actions it need to do to support
- the control loop type in question. Control Loop Priming takes place at participant
- registration and at Control Loop Commissioning. The post condition for an execution of this
- capability is that all participants in this control loop type are commissioned, that is they
- are prepared to run instances of their Control Loop Element types.
-
-
-At Run Time, the following Control Loop Life Cycle management capabilities are supported:
-
-#. **Control Loop Commissioning:** This capability allows version controlled Control Loop Type
- definitions to be taken from the Control Loop Design Time Catalogue and be placed in the
- Commissioned Control Loop Inventory. It also allows the values of Common Property Types
- that apply to all instances of a Control Loop Type to be set. Further, the Control Loop
- Type is primed on all concerned participants. The post condition for an execution of this
- capability is that the Control Loop Type definition is in the Commissioned Control Loop
- Inventory and the Control Loop Type is primed on concerned participants.
-
-#. **Control Loop Instance Life Cycle Management:** This capability allows a Control Loop
- Instance to have its life cycle managed.
-
- #. **Control Loop Instance Creation:** This capability allows a Control Loop Instance to be
- created. The Control Loop Type definition is read from the Commissioned Control Loop
- Inventory and values are assigned to the Instance Specific Property Types defined for
- instances of the Control Loop Type in the same manner as the existing CLAMP client does.
- A Control Loop Instance that has been created but has not yet been instantiated on
- participants is in state UNINITIALIZED. In this state, the Instance Specific Property Type
- values can be revised and updated as often as the user requires. The post condition for an
- execution of this capability is that the Control Loop instance is created in the
- Instantiated Control Loop Inventory but has not been instantiated on Participants.
-
- #. **Control Loop Instance Update on Participants:** Once the user is happy with the property
- values, the Control Loop Instance is updated on participants and the Control Loop Elements
- for this Control Loop Instance are initialized or updated by participants using the control
- loop metadata. The post condition for an execution of this capability is that the Control
- Loop instance is updated on Participants.
-
- #. **Control Loop State Change:** The user can now order the participants to change the state
- of the Control Loop Instance. If the Control Loop is set to state RUNNING, each participant
- begins accepting and processing control loop events and the Control Loop Instance is set
- to state RUNNING in the Instantiated Control Loop inventory. The post condition for an
- execution of this capability is that the Control Loop instance state is changed on
- participants.
-
- #. **Control Loop Instance Monitoring:** This capability allows Control Loop Instances to be
- monitored. Users can check the status of Participants, Control Loop Instances, and Control
- Loop Elements. Participants report their overall status and the status of Control Loop
- Elements they are running periodically to CLAMP. Clamp aggregates these status reports
- into an aggregated Control Loop Instance status record, which is available for monitoring.
- The post condition for an execution of this capability is that Control Loop Instances are
- being monitored.
-
- #. **Control Loop Instance Supervision:** This capability allows Control Loop Instances to be
- supervised. The CLAMP runtime expects participants to report on Control Loop Elements
- periodically. The CLAMP runtime checks that periodic reports are received and that each
- Control Loop Element is in the state it should be in. If reports are missed or if a
- Control Loop Element is in an incorrect state, remedial action is taken and notifications
- are issued. The post condition for an execution of this capability is that Control Loop
- Instances are being supervised by the CLAMP runtime.
-
- #. **Control Loop Instance Removal from Participants:** A user can order the removal of a Control
- Loop Instance from participants. The post condition for an execution of this capability is
- that the Control Loop instance is removed from Participants.
-
- #. **Control Loop Instance Deletion:** A user can order the removal of a Control Loop Instance
- from the CLAMP runtime. Control Loop Instances that are instantiated on participants cannot
- be removed from the CLAMP runtime. The post condition for an execution of this capability
- is that the Control Loop instance is removed from Instantiated Control Loop Inventory.
-
-#. **Control Loop Decommissioning:** This capability allows version controlled Control Loop Type
- definitions to be removed from the Commissioned Control Loop Inventory. A Control Loop
- Definition that has instances in the Instantiated Control Loop Inventory cannot be removed.
- The post condition for an execution of this capability is that the Control Loop Type
- definition removed from the Commissioned Control Loop Inventory.
-
-.. note::
- The system dialogues for run time capabilities are described in detail on the
- :ref:`System Level Dialogues <system-level-label>` page.
-
-.. _controlloop-instance-states:
-
-2.1 Control Loop Instance States
---------------------------------
-
-When a control loop definition has been commissioned, instances of the control loop can be
-created, updated, and deleted. The system manages the lifecycle of control loops and control
-loop elements following the state transition diagram below.
-
-.. image:: images/03-controlloop-instance-states.png
-
-3 Overall Target Architecture
-=============================
-
-The diagram below shows an overview of the architecture of TOSCA based Control Loop
-Management in CLAMP.
-
-.. image:: images/04-overview.png
-
-Following the ONAP Reference Architecture, the architecture has a Design Time part and
-a Runtime part.
-
-The Design Time part of the architecture allows a user to specify metadata for participants.
-It also allows users to compose control loops. The Design Time Catalogue contains the metadata
-primitives and control loop definition primitives for composition of control loops. As shown
-in the figure above, the Design Time component provides a system where Control Loops can be
-designed and defined in metadata. This means that a Control Loop can have any arbitrary
-structure and the Control Loop developers can use whatever analytic, policy, or control
-participants they like to implement their Control Loop. At composition time, the user
-parameterises the Control Loop and stores it in the design time catalogue. This catalogue
-contains the primitive metadata for any participants that can be used to compose a Control
-Loop. A Control Loop SDK is used to compose a Control Loop by aggregating the metadata for
-the participants chosen to be used in a Control Loop and by constructing the references between
-the participants. The architecture of the Control Loop Design Time part will be elaborated in
-future releases.
-
-Composed Control Loops are commissioned on the run time part of the system, where they are
-stored in the Commissioned Control Loop inventory and are available for instantiation. The
-Commissioning component provides a CRUD REST interface for Control Loop Types, and implements
-CRUD of Control Loop Types. Commissioning also implements validation and persistence of incoming
-Control Loop Types. It also guarantees the integrity of updates and deletions of Control Loop
-Types, such as performing updates in accordance with semantic versioning rules and ensuring that
-deletions are not allowed on Control Loop Types that have instances defined.
-
-The Instantiation component manages the Life Cycle Management of Control Loop Instances and
-their Control Loop Elements. It publishes a REST interface that is used to create Control Loop
-Instances and set values for Common and Instance Specific properties. This REST interface is
-public and is used by the CLAMP GUI. It may also be used by any other client via the public
-REST interface. the REST interface also allows the state of Control Loop Instances to be changed.
-A user can change the state of Control Loop Instances as described in the state transition
-diagram shown in section 2 above. The Instantiation component issues update and state change
-messages via DMaaP to participants so that they can update and manage the state of the Control
-Loop Elements they are responsible for. The Instantiation component also implements persistence
-of Control Loop Instances, control loop elements, and their state changes.
-
-The Monitoring component reads updates sent by participants. Participants report on the
-state of their Control Loop Elements periodically and in response to a message they have
-received from the Instantiation component. The Monitoring component reads the contents of
-the participant messages and persists their state updates and statistics records. It also
-publishes a REST interface that publishes the current state of all Participants, Control
-Loop Instances and their Control Loop Elements, as well as publishing Participant and
-Control Loop statistics.
-
-The Supervision component is responsible for checking that Control Loop Instances are correctly
-instantiated and are in the correct state (UNINITIALIZED/READY/RUNNING). It also handles
-timeouts and on state changes to Control Loop Instances, and retries and rolls back state
-changes where state changes failed.
-
-A Participant is an executing component that partakes in control loops. More explicitly, a
-Participant is something that implements the Participant Instantiation and Participant
-Monitoring messaging protocol over DMaaP for Life Cycle management of Control Loop Elements.
-A Participant runs Control Loop Elements and manages and reports on their life cycle
-following the instructions it gets from the CLAMP runtime in messages delivered over DMaaP.
-
-In the figure above, five participants are shown. A Configuration Persistence Participant
-manages Control Loop Elements that interact with the `ONAP Configuration Persistence Service
-<https://docs.onap.org/projects/onap-cps/en/latest/overview.html>`_
-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. Other Considerations
-=======================
-
-.. _management-cl-instance-configs:
-
-4.1 Management of Control Loop Instance Configurations
-------------------------------------------------------
-
-In order to keep management of versions of the configuration of control loop instances
-straightforward and easy to implement, the following version management scheme using
-semantic versioning is implemented. Each configuration of a Control Loop Instance and
-configuration of a Control Loop Element has a semantic version with 3 digits indicating
-the **major.minor.patch** number of the version.
-
-.. note::
- A **configuration** means a full set of parameter values for a Control Loop Instance.
-
-.. image:: images/05-upgrade-states.png
-
-Change constraints:
-
-#. 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.
-
-#. 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**.
-
-#. 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.
-
-#. 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 Instantiated Control Loop 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.
-
-When a request is broadcast on DMaaP, the request is asynchronously picked up by participants
-of the types required for the Control Loop Instance and those participants manage the life
-cycle of its control loop elements. Periodically, each participant reports back on the status
-of operations it has picked up for the Control Loop Elements it controls, together with
-statistics on the Control Loop Elements over DMaaP. On reception of these participant messages,
-the CLAMP runtime stores this information to its database.
-
-The participant to use on a control loop can be selected from the registered participants
-in either of two ways:
-
-**Runtime-side Selection:** The CLAMP runtime selects a suitable participant from the list of
-participants and sends the participant ID that should be used in the Participant Update message.
-In this case, the CLAMP runtime decides on which participant will run the Control Loop Element
-based on a suitable algorithm. Algorithms could be round robin based or load based.
-
-**Participant-side Selection:** The CLAMP runtime sends a list of Participant IDs that may be used
-in the Participant Update message. In this case, the candidate participants decide among
-themselves which participant should host the Control Loop Element.
-
-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.
-
-
-4.3 Sandboxing and API Gateway Support
---------------------------------------
-
-At runtime, interaction between ONAP platform services and application microservices are
-relatively unconstrained, so interactions between Control Loop Elements for a given Control
-Loop Instance remain relatively unconstrained. A
-`proposal to support access-controlled access to and between ONAP services
-<https://wiki.onap.org/pages/viewpage.action?pageId=103417456>`_
-will improve this. This can be complemented by intercepting and controlling services
-accesses between Control Loop Elements for Control Loop Instances for some/all Control
-Loop types.
-
-API gateways such as `Kong <https://konghq.com/kong/>`_ have emerged as a useful technology
-for exposing and controlling service endpoint access for applications and services. When a
-Control Loop Type is onboarded, or when Control Loop Instances are created in the Participants,
-CLAMP can configure service endpoints between Control Loop Elements to redirect through an
-API Gateway.
-
-Authentication and access-control rules can then be dynamically configured at the API gateway
-to support constrained access between Control Loop Elements and Control Loop Instances.
-
-The diagram below shows the approach for configuring API Gateway access at Control Loop
-Instance and Control Loop Element level.
-
-.. image:: images/06-api-gateway-sandbox.png
-
-At design time, the Control Loop type definition specifies the type of API gateway configuration
-that should be supported at Control Loop and Control Loop Element levels.
-
-At runtime, the CLAMP can configure the API gateway to enable (or deny) interactions between
-Control Loop Instances and individually for each Control Loop Element. All service-level
-interactions in/out of a Control Loop Element, except that to/from the API Gateway, can be
-blocked by networking policies, thus sandboxing a Control Loop Element and an entire Control
-Loop Instance if desired. Therefore, a Control Loop Element will only have access to the APIs
-that are configured and enabled for the Control Loop Element/Instance in the API gateway.
-
-For some Control Loop Element Types the Participant can assist with service endpoint
-reconfiguration, service request/response redirection to/from the API Gateway, or
-annotation of requests/responses.
-
-Once the Control Loop instance is instantiated on participants, the participants configure
-the API gateway with the Control Loop Instance level configuration and with the specific
-configuration for their Control Loop Element.
-
-Monitoring and logging of the use of the API gateway may also be provided. Information and
-statistics on API gateway use can be read from the API gateway and passed back in monitoring
-messages to the CLAMP runtime.
-
-Additional isolation and execution-environment sandboxing can be supported depending on the
-Control Loop Element Type. For example: ONAP policies for given Control Loop Instances/Types
-can be executed in a dedicated PDP engine instances; DCAE or K8S-hosted services can executed
-in isolated namespaces or in dedicated workers/clusters; etc..
-
-
-5 APIs and Protocols
-====================
-
-The APIs and Protocols used by CLAMP for Control Loops are described on the pages below:
-
-#. :ref:`System Level Dialogues <system-level-label>`
-#. :ref:`Defining Control Loops in TOSCA for CLAMP <defining-controlloops-label>`
-#. :ref:`The CLAMP Control Loop Participant Protocol <controlloop-participant-protocol-label>`
-#. :ref:`REST APIs for CLAMP Control Loops <controlloop-rest-apis-label>`
-
-
-6 Design and Implementation
-===========================
-
-The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
-
-#. The CLAMP Runtime Server
-#. CLAMP Participants
-#. The CLAMP GUI
-#. Building and running CLAMP
-#. Testing CLAMP
-
-End of Document
+ controlloop-architecture
+ defining-controlloops
+ api-protocol/api-protocol
+ design-impl/design-impl
in Control Loop and Control Loop Element definitions. For example, the chart parameter on a
Kubernetes Control Loop Element has a different value for every instance of a Kubernetes Control
Loop Element, so it can be defined as shown below in the :ref:`Kubernetes Control Loop Type definition
-<_kubernetes-cl-element>` yaml file.
+<kubernetes-cl-element>` yaml file.
.. code-block:: yaml
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-runtime:
+
+The CLAMP Control Loop Runtime
+##############################
+
+To be completed.
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-gui-controlloop:
+
+The CLAMP GUI for Control Loops
+###############################
+
+To be completed.
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-design-impl:
+
+CLAMP TOSCA Control Loop Components: Design and Implementaiton
+##############################################################
+
+The sections below describe the components that handle TOSCA Control Loops.
+
+.. toctree::
+ :maxdepth: 1
+
+ clamp-controlloop-runtime
+ clamp-gui-controlloop
+ participants/participants
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-http-participant:
+
+HTTP Participant
+################
+
+.. warning:: To be completed
+
+The CLAMP HTTP participant receives configuration information from the CLAMP runtime,
+maps the configuration information to a REST URL, and makes a REST call on the URL.
+Typically the HTTP Participant is used with another participant such as the
+:ref:`Kubernetes Participant <clamp-controlloop-k8s-participant>`, which brings up
+the microservice that runs a REST server. Once the microservice is up, the HTTP
+participant can be used to configure the microservice over its REST interface.Of course,
+the HTTP participant works towards any REST service, it is not restricted to REST
+services started by participants.
+
+.. image:: ../../images/participants/http-participant.png
+
+The HTTP participant runs a Control Loop Element to handle the REST dialogues for a
+particular application domain. The REST dialogues are whatever REST calls that are
+required to implement the functionality for the application domain.
+
+The HTTP participant allows the REST dialogues for a Control Loop to be managed. A
+particular Control Loop may require many *things* to be configured and managed and this
+may require many REST dialogues to achieve.
+
+A *Configuration Entity* describes a concept that is managed by the HTTP participant. A
+Configuration Entity can be created, Read, Updated, and Deleted (CRUD). The user defines
+the Configuration Entities that it wants its HTTP Control Loop Element to manage and
+provides a sequence of parameterized REST commands to Create, Read, Update, and Delete
+each Configuration Entity.
+
+When a control loop is initialized, the HTTP participant starts a HTTP Control Loop
+element for the control loop. It reads the configuration information sent from the
+Control Loop Runtime runs a HTTP client to talk to the REST endpoint that is receiving
+the REST requests. A HTTP participant can simultaneously manage HTTP Control Loop
+Elements towards multiple REST endpoints, as shown in the diagram above where the HTTP
+participant is running two HTTP Control Loop Elements, one for Control Loop A and one for
+Control Loop B.
+
+Configuring a Control Loop Element on the HTTP participant for a Control Loop
+-----------------------------------------------------------------------------
+
+The user configures the following properties in the CLAMP GUI for the HTTP participant:
+
+.. list-table::
+ :widths: 15 10 50
+ :header-rows: 1
+
+ * - Property
+ - Type
+ - Description
+ * - baseUrl
+ - URL
+ - A well formed URL pointing at the REST server that is processing the REST requests
+ * - httpHeaders
+ - map
+ - A map of *<String, String>* defining the HTTP headers to send on all REST calls
+ * - configurationEntitiies
+ - map
+ - A map of *<String, ConfigurationEntity>* describing the names and definitions of
+ configuration entities that are managed by this HTTP Control Loop Element
+
+The *ConfigurationEntity* type is described in the following table:
+
+.. list-table::
+ :widths: 15 10 50
+ :header-rows: 1
+
+ * - Field
+ - Type
+ - Description
+ * - ID
+ - ToscaConceptIdentifier
+ - The name and version of the Configuration Entity
+ * - restSequence
+ - List<RestRequest>
+ - A list of REST requests to give manage the Configuration Entity
+
+The *RestRequest* type is described in the following table:
+
+.. list-table::
+ :widths: 15 10 50
+ :header-rows: 1
+
+ * - Field
+ - Type
+ - Description
+ * - httpMethod
+ - HttpMethod
+ - An enum for the HTTP method {GET, PUT, POST, DELETE}
+ * - path
+ - String
+ - The path of the REST endopint relative to the baseUrl
+ * - body
+ - String
+ - The body of the request for POST and PUT methods
+ * - expectedResponse
+ - HttpStatus
+ - The expected HTTP response code fo the REST request
+
\ No newline at end of file
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-k8s-participant:
+
+Kubernetes Participant
+######################
+
+.. warning:: To be completed
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-participant-intermediary:
+
+Participant Intermediary
+########################
+
+The CLAMP Participant Intermediary is a common library in ONAP, which does common message and
+state handling for participant implementations. It provides a Java API, which participant
+implementations implement to receive and send messages to the CLAMP runtime and to handle
+Control Loop Element state.
+
+.. warning:: To be completed
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-participant-simulator:
+
+Participant Simulator
+#####################
+
+To be completed.
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-participants:
+
+Control Loop Participants
+#########################
+
+A Participant is a component that acts as a bridge between the CLAMP COntrol Loop runtime and components such as
+the Policy Framework, DCAE, or a Kubernetes cluster that are taking part in control loops. It listens
+to DMaaP to receive messages from the CLAMP runtime and performs operations towards components that
+are taking part in control loops. A participant has a Control Loop Element for each control loop in
+which it is taking part.
+
+The implementation of a participant may use a common
+:ref:`Participant Intermediary library <clamp-controlloop-participant-intermediary>`, which carries out common
+message and state handling for Control Loop Elements in participants. The *ParticipantImpelementation* is the
+component specific implementation of a participant, which is specifically developed for each component that
+wishes to take part in control loops.
+
+.. image:: ../../images/participants/participants.png
+
+The figure above shows participants for various components that may take part in control loops.
+
+.. note:: The figure above is for illustration. Not all the participants mentioned above
+ have realizations in ONAP. Some of the participants in the figure above represent
+ a type of participant. For example, a controller participant would be written for
+ a specific controller such as CDS and a participant for an existing system would be
+ written towards that existing system.
+
+The detailed implementation of the CLAMP Participant ecosystem is described on the following pages:
+
+.. toctree::
+ :maxdepth: 1
+
+ participant-intermediary
+ http-participant
+ k8s-participant
+ policy-framework-participant
+ participant-simulator
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-controlloop-policy-framework-participant:
+
+Policy Framework Participant
+############################
+
+To be completed.
Code Review / policy / parent.git / commitdiff
