4. Other Considerations
=======================
-.. _management-cl-instance-configs:
+.. _management-acm-instance-configs:
4.1 Management of Automation Composition Instance Configurations
----------------------------------------------------------------
The design and implementation of TOSCA Automation Compositions in CLAMP is described for each executable entity on the pages below:
-#. :ref:`The CLAMP Automation Composition Runtime Server <clamp-acm-runtime>`
+#. :ref:`The CLAMP Automation Composition Runtime Server <clamp-runtime-acm>`
#. :ref:`CLAMP Automation Composition Participants <clamp-acm-participants>`
#. :ref:`Managing Automation Compositions using The CLAMP GUI <clamp-gui-acm>`
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _acm-participant-protocol-label:
+
+The ACM Automation Composition Participant Protocol
+###################################################
+
+The CLAMP Automation Composition protocol is an asynchronous protocol that is used by the CLAMP
+runtime to coordinate lifecycle management of Automation Composition instances. The protocol
+supports the functions described in the sections below.
+
+
+Protocol Dialogues
+==================
+
+The protocol supports the dialogues described below.
+
+Participant Registration and De-Registration
+--------------------------------------------
+
+Registration when a participant comes up and update of participant with Automation Composition type
+information and common parameter values for its Automation Composition types.
+
+.. image:: ../images/acm-participants-protocol/participant-registering.png
+
+
+De-registration is executed as a participant goes down.
+
+.. image:: ../images/acm-participants-protocol/participant-deregistration.png
+
+
+Automation Composition Priming and De-Priming
+---------------------------------------------
+
+When an Automation Composition is primed, the portion of the Automation Composition Type Definition
+and Common Property values for the participants of each participant type mentioned in the
+Automation Composition Definition are sent to the participants.
+
+.. image:: ../images/acm-participants-protocol/acm-priming.png
+
+When an Automation Composition is de-primed, the portion of the Automation Composition Type
+Definition and Common Property values for the participants of each participant type mentioned in
+the Automation Composition Definition are deleted on participants.
+
+.. image:: ../images/acm-participants-protocol/acm-depriming.png
+
+
+Automation Composition Update
+-----------------------------
+
+Automation Composition Update handles creation, change, and deletion of Automation Compositions on
+participants. Change of Automation Compositions uses a semantic versioning approach and follows the
+semantics described on the page :ref:`4.1 Management of Automation Composition Instance
+Configurations <management-acm-instance-configs>`.
+
+.. image:: ../images/acm-participants-protocol/acm-update.png
+
+The handling of an *ACMUpdate* message in each participant is as shown below.
+
+.. image:: ../images/acm-participants-protocol/acm-update-msg.png
+
+Automation Composition State Change
+-----------------------------------
+
+This dialogue is used to change the state of Automation Compositions and their Automation
+Composition Elements. The CLAMP Runtime sends an Automation Composition State Change message on the
+Automation Composition to all participants. Participants that have Automation Composition Elements
+in that Automation Composition attempt an update on the state of the Automation Composition
+elements they have for that Automation Composition, and report the result back.
+
+The *startPhase* in the `Definition of TOSCA fundamental Automation Composition Types
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+is particularly important in Automation Composition state changes because sometimes the user wishes
+to control the order in which the state changes in Automation Composition Elements in an Automation
+Composition. In-state changes from *UNITITIALISED → PASSIVE* and from *PASSIVE → RUNNING*,
+Automation Composition elements are started in increasing order of their startPhase. In-state
+changes from *RUNNING → PASSIVE* and from *PASSIVE → UNITITIALISED*, Automation Composition
+elements are started in decreasing order of their *startPhase*.
+
+The CLAMP runtime controls the state change process described in the diagram below. The CLAMP
+runtime sends an Automation Composition state change message on DMaaP to all participants in a
+particular start phase so, in each state change multiple Automation Composition State Change
+messages are sent, one for each start phase in the Automation Composition. If more than one
+Automation Composition Element has the same start phase, those Automation Composition Elements
+receive the same Automation Composition State Change message from DMaaP and start in parallel.
+
+The Participant reads each State Change Message it sees on DMaaP. If the start phase on the
+Automation Composition State Change message matches the Start Phase of the Automation Composition
+Element, the participant processes the state change message. Otherwise, the participant ignores the
+message.
+
+.. image:: ../images/acm-participants-protocol/acm-state-change.png
+
+The handling of an ACMStateChange message in each participant is as shown below.
+
+.. image:: ../images/acm-participants-protocol/acm-state-change-msg.png
+
+Automation Composition Monitoring and Reporting
+-----------------------------------------------
+
+This dialogue is used as a heartbeat mechanism for participants, to monitor the status of
+Automation Composition Elements, and to gather statistics on Automation Compositions. The
+*ParticipantStatus* message is sent periodically by each participant. The reporting interval for
+sending the message is configurable.
+
+.. image:: ../images/acm-participants-protocol/acm-monitoring.png
+
+
+Messages
+========
+
+The CLAMP Automation Composition Participant Protocol uses the following messages. The
+descriptions below give an overview of each message. For the precise definition of the messages,
+see the `CLAMP code at Github
+<https://github.com/onap/policy-clamp/tree/master/models/src/main/java/org/onap/policy/clamp/models/acm/messages/dmaap/participant>`_
+. All messages are carried on DMaaP.
+
+
+.. list-table::
+ :widths: 15 10 10 15 15 35
+ :header-rows: 1
+
+ * - Message
+ - Source
+ - Target
+ - Purpose
+ - Important Fields
+ - Field Descriptions
+ * - ParticipantRegister
+ - Participant
+ - CLAMP Runtime
+ - Participant registers with the CLAMP runtime
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * - ParticipantRegisterAck
+ - CLAMP Runtime
+ - Participant
+ - Acknowledgment of Participant Registration
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantUpdate
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime sends Automation Composition Element Definitions and Common Parameter Values
+ to Participants
+ - ParticipantDefinitionUpdateMap
+ - Map with Participant ID as its key, each value on the map is an ACMElementDefintionMap
+ * -
+ -
+ -
+ -
+ - ACMElementDefintionMap
+ - List of ACMElementDefinition values for a particular participant, keyed by its Automation
+ Composition Element Definition ID
+ * -
+ -
+ -
+ -
+ - ACMElementDefinition
+ - An ACMElementToscaServiceTemplate containing the definition of the Automation Composition
+ Element and a CommonPropertiesMap with the values of the common property values for
+ Automation Composition Elements of this type
+ * -
+ -
+ -
+ -
+ - ACMElementToscaServiceTemplate
+ - The definition of the Automation Composition Element in TOSCA
+ * -
+ -
+ -
+ -
+ - CommonPropertiesMap
+ - A <String, String> map indexed by the property name. Each map entry is the serialized value
+ of the property, which can be deserialized into an instance of the type of the property.
+ * - ParticipantUpdateAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Participant Update
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantDeregister
+ - Participant
+ - CLAMP Runtime
+ - Participant deregisters with the CLAMP runtime
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * - ParticipantDeregisterAck
+ - CLAMP Runtime
+ - Participant
+ - Acknowledgment of Participant Deegistration
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ACMUpdate
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime sends Automation Composition Element instances and Instance Specific Parameter
+ Values for an Automation Composition Instance to Participants
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - ParticipantUpdateMap
+ - Map with Participant ID as its key, each value on the map is an ACMElementList
+ * -
+ -
+ -
+ -
+ - ACMElementList
+ - List of ACMElement values for the Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMElement
+ - An ACMElement, which contains among other things a PropertiesMap with the values of the
+ property values for this Automation Composition Element instance and a
+ ToscaServiceTemplateFragment with extra concept definitions and instances that a participant
+ may need.
+ * -
+ -
+ -
+ -
+ - PropertiesMap
+ - A <String, String> map indexed by the property name. Each map entry is the serialized value
+ of the property, which can be deserialized into an instance of the type of the property.
+ * -
+ -
+ -
+ -
+ - ToscaServiceTemplateFragment
+ - A well-formed TOSCA service template containing extra concept definitions and instances that
+ a participant may need. For example, the Policy Participant may need policy type definitions
+ or policy instances to be provided if they are not already stored in the Policy Framework.
+ * - ACMUpdateAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Automation Composition Update
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMResult
+ - Holds a Result and Message for the overall operation on the participant and a map of Result
+ and Message fields for each Automation Composition Element of the Automation Composition on
+ this participant
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ACMStateChange
+ - CLAMP Runtime
+ - Participant
+ - CLAMP Runtime asks Participants to change the state of an Automation Composition
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - currentState
+ - The current state of the Automation Composition
+ * -
+ -
+ -
+ -
+ - orderedState
+ - The state that the Automation Composition should transition to
+ * -
+ -
+ -
+ -
+ - startPhase
+ - The start phase to which this ACMStateChange message applies
+ * - ACMStateChangeAck
+ - Participant
+ - CLAMP Runtime
+ - Acknowledgment of Automation Composition State Change
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ACMId
+ - The name and version of the Automation Composition
+ * -
+ -
+ -
+ -
+ - startPhase
+ - The start phase to which this ACMStateChangeAck message applies
+ * -
+ -
+ -
+ -
+ - ACMResult
+ - Holds a Result and Message for the overall operation on the participant and a map of Result
+ and Message fields for each Automation Composition Element of the Automation Composition on
+ this participant
+ * -
+ -
+ -
+ -
+ - Result
+ - Success/Fail
+ * -
+ -
+ -
+ -
+ - Message
+ - A message indicating the reason for failure
+ * - ParticipantStatusReq
+ - CLAMP Runtime
+ - Participant
+ - Request that the specified participants return a ParticipantStatus message immediately
+ - ParticipantId
+ - The ID of this participant, if not specified, all participants respond.
+ * - ParticipantStatus
+ - Participant
+ - CLAMP Runtime
+ - Periodic or on-demand report for heartbeat, Participant Status, Automation Composition
+ Status, and Automation Composition Statistics
+ - ParticipantId
+ - The ID of this participant
+ * -
+ -
+ -
+ -
+ - ParticipantType
+ - The type of the participant; maps to the capabilities of the participant in Automation
+ Composition Type Definitions
+ * -
+ -
+ -
+ -
+ - ParticipantDefinitionUpdateMap (returned in repsonse to ParticipantStatusReq only)
+ - See ParticipantUpdate message above for definition of this field
+ * -
+ -
+ -
+ -
+ - ParticipantStatus
+ - The current status of the participant for monitoring
+ * -
+ -
+ -
+ -
+ - ParticipantStatistics
+ - Statistics on the participant such as uptime, or messages processed. Can include participant
+ specific data in a string blob that is opaque to CLAMP
+ * -
+ -
+ -
+ -
+ - ACMInfoMap
+ - A map of ACMInfo types indexed by ACMId, one entry for each Automation Composition
+ running on the participant
+ * -
+ -
+ -
+ -
+ - ACMInfo
+ - The ACMStatus and ACMStatistics for a given Automation Composition
+ * -
+ -
+ -
+ -
+ - ACMStatus
+ - The current status of the Automation Composition for monitoring
+ * -
+ -
+ -
+ -
+ - ACMStatistics
+ - Statistics on the Automation Composition such as uptime, or messages processed. Can include
+ participant specific data in a string blob that is opaque to CLAMP
+
+
+End of Document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _acm-rest-apis-label:
+
+REST APIs for CLAMP Automation Compositions
+###########################################
+
+
+Commissioning API
+=================
+
+This API is a CRUD API that allows Automation Composition Type definitions created in a design
+environment to be commissioned on the CLAMP runtime. It has endpoints that allow Automation
+Composition Types to be created, read, updated, and deleted.
+
+The body of the create and update end points is a TOSCA Service/Topology template that
+defines the new or changed Automation Composition Type. The update and delete endpoints take a
+reference to the Automation Composition Type. The incoming TOSCA is verified and checked for
+referential integrity. On delete requests, a check is made to ensure that no Automation
+Composition Instances exist for the Automation Composition Type to be deleted.
+
+.. swaggerv2doc:: swagger/acm-comissioning.json
+
+
+Instantiation API
+=================
+
+The instantiation API has two functions:
+
+#. Creation, Reading, Update, and Deletion of Automation Composition Instances.
+#. Instantiation and lifecycle management of Automation Composition Instances on participants.
+
+The Instantiation API is used by the CLAMP GUI.
+
+Instantiation Automation Composition Instance CRUD
+--------------------------------------------------
+
+This sub API allows for the creation, read, update, and deletion of Automation Composition
+Instances. The endpoints for create and update take a JSON body that describes the Automation
+Composition Instance. The endpoints for read and delete take a Automation Composition Instance
+ID to determine which Automation Composition Instance to act on. For the delete endpoint, a check
+is made to ensure that the Automation Composition Instance is not instantiated on participants.
+
+A call to the update endpoint for a Automation Composition Instance follows the semantics described
+here: :ref:`4.1 Management of Automation Composition Instance Configurations
+<management-acm-instance-configs>`.
+
+.. swaggerv2doc:: swagger/acm-instantiation.json
+
+
+Instantiation Automation Composition Instance Lifecycle Management
+------------------------------------------------------------------
+
+This sub API is used to manage the lifecycle of Automation Composition Instances. An Automation
+Composition Instance can be in the states described here: :ref:`2.1 Automation Composition Instance
+States <acm-instance-states>`. Managing the lifecycle of an Automation Composition Instance amounts
+to steering the Automation Composition through its states.
+
+The sub API allows upgrades and downgrades of Automation Composition Instances to be pushed to
+participants following the semantics described here: :ref:`4.1 Management of Automation Composition
+Instance Configurations <management-acm-instance-configs>`. When the API is used to update the
+participants on a Automation Composition Instance, the new/upgraded/downgraded definition of the
+Automation Composition is pushed to the participants. Note that the API asks the participants in an
+Automation Composition Instance to perform the update, it is the responsibility of the participants
+to execute the update and report the result using the protocols described here: :ref:`CLAMP
+Participants <clamp-acm-participants>`. The progress and result of an update can be monitored
+using the :ref:`Monitoring API <monitoring-api>`.
+
+The sub API also allows a state change of an Automation Composition Instance to be ordered. The
+required state of the Automation Composition Instance is pushed to participants in an Automation
+Composition Instance using the API. Note that the API asks the participants in an Automation
+Composition Instance to perform the state change, it is the responsibility of the participants to
+execute the state change and report the result using the protocols described here: :ref:`CLAMP
+Participants <clamp-acm-participants>`. The progress and result of a state change can be monitored
+using the `Monitoring API <monitoring-api>`.
+
+.. warning::
+ The Swagger for the Instantiation Lifecycle Management API will appear here.
+
+.. _monitoring-api:
+
+Monitoring API
+==============
+
+The Monitoring API allows the state and statistics of Participants, Automation Composition
+Instances and their Automation Composition Elements to be monitored. This API is used by the CLAMP
+GUI. The API provides filtering so that specific Participants and Automation Composition Instances
+can be retrieved. In addition, the quantity of statistical information to be returned can be
+scoped.
+
+.. swaggerv2doc:: swagger/acm-monitoring.json
+
+Pass Through API
+================
+
+This API allows information to be passed to Automation Composition Elements in an Automation
+Composition.
+
+.. warning::
+ The requirements on this API are still under discussion.
+
+.. warning::
+ The Swagger for the Pass Through API will appear here.
+
+
+Participant Standalone API
+==========================
+
+This API allows a Participant to run in standalone mode and to run standalone Automation
+Composition Elements.
+
+Kubernetes participant can also be deployed as a standalone application and provides REST endpoints
+for onboarding helm charts to its local chart storage, installing and uninstalling of helm charts
+to a Kubernetes cluster. It also allows to configure a remote repository in Kubernetes participant
+for installing helm charts. User can onboard a helm chart along with the overrides YAML file, the
+chart gets stored in the local chart directory of Kubernetes participants. The onboarded charts can
+be installed and uninstalled. The GET API fetches all the available helm charts from the chart
+storage.
+
+.. swaggerv2doc:: swagger/k8sparticipant.json
+
+
+Participant Simulator API
+=========================
+
+This API allows a Participant Simulator to be started and run for test purposes.
+
+.. swaggerv2doc:: swagger/participant-sim.json
+
+End of Document
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-api-protocol:
+.. _clamp-acm-api-protocol:
-CLAMP TOSCA Control Loop APIs and Protocols
-###########################################
+CLAMP TOSCA Automation Composition APIs and Protocols
+#####################################################
The sections below describe the APIs and Protocols used in TOSCA Control Loops.
:maxdepth: 1
system-level-dialogues
- controlloop-participant-protocol
- controlloop-rest-apis
+ acm-participant-protocol
+ acm-rest-apis
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _controlloop-participant-protocol-label:
-
-The CLAMP Control Loop Participant Protocol
-###########################################
-
-The CLAMP Control Loop Participant protocol is an asynchronous protocol that is used by the
-CLAMP runtime to coordinate life cycle management of Control Loop instances. The protocol
-supports the functions described in the sections below.
-
-
-Protocol Dialogues
-==================
-
-The protocol supports the dialogues described below.
-
-Participant Registration and De-Registration
---------------------------------------------
-
-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
-
-
-De-registration is executed as a participant goes down.
-
-.. image:: ../images/clamp-cl-participants/participant-deregistration.png
-
-
-Control Loop Priming and De-Priming
------------------------------------
-
-When a control loop is 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 sent to the participants.
-
-.. 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
-
-
-Control Loop Update
--------------------
-
-Control Loop Update handles creation, change, and deletion of control loops on participants.
-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
-
-The handling of a ControlLoopUpdate message in each participant is as shown below.
-
-.. image:: ../images/clamp-cl-participants/controlloop-update-msg.png
-
-Control Loop State Change
--------------------------
-
-This dialogue is used to change the state of Control Loops and their Control Loop Elements. The
-CLAMP Runtime sends a Control Loop State Change message on the control loop to all participants.
-Participants that have Control Loop Elements in that Control Loop attempt an update on the state
-of the control loop elements they have for that control loop, and report the result back.
-
-The *startPhase* in the `Definition of TOSCA fundamental Control Loop Types
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-is particularly important in control loop state changes because sometime the user wishes to control
-the order in which the state changes in Control Loop Elements in a control loop. In state changes
-from *UNITITIALISED* → *PASSIVE* and from *PASSIVE* → *RUNNING*, control loop elements are started in
-increasing order of their *startPhase*. In state changes from *RUNNING* → *PASSIVE* and from *PASSIVE*
-→ *UNITITIALISED*, control loop elements are started in decreasing order of their *startPhase*.
-
-The CLAMP runtime controls the state change process described in the diagram below. The CLAMP runtime
-sends a Control Loop State Change message on DMaaP to all participants in a particular Start Phase so,
-in each state change multiple Control Loop State Change messages are sent, one for each Start Phase in
-the control loop. If more than one Control Loop Element has the same Start Phase, those Control Loop
-Elements receive the same Control Loop State Change message from DMaaP and start in parallel.
-
-The Participant reads each State Change Message it sees on DMaaP. If the Start Phase on the Control
-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
-
-The handling of a ControlLoopStateChange message in each participant is as shown below.
-
-.. image:: ../images/clamp-cl-participants/controlloop-state-change-msg.png
-
-Control Loop Monitoring and Reporting
--------------------------------------
-
-This dialogue is used as a heartbeat mechanism for participants, to monitor the status of Control Loop
-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
-
-
-Messages
-========
-
-The CLAMP Control Loop Participant Protocol uses the following messages. The descriptions below give
-an overview of each message. For the precise definition of the messages, see the `CLAMP code at Github
-<https://github.com/onap/policy-clamp/tree/master/models/src/main/java/org/onap/policy/clamp/controlloop/models/messages/dmaap/participant>`_
-. All messages are carried on DMaaP.
-
-
-.. list-table::
- :widths: 15 10 10 15 15 35
- :header-rows: 1
-
- * - Message
- - Source
- - Target
- - Purpose
- - Important Fields
- - Field Descriptions
- * - ParticipantRegister
- - Participant
- - CLAMP Runtime
- - Participant registers with the CLAMP runtime
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * - ParticipantRegisterAck
- - CLAMP Runtime
- - Participant
- - Acknowledgement of Participant Registration
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantUpdate
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime sends Control Loop Element Definitions and Common Parameter Values to Participants
- - ParticipantDefinitionUpdateMap
- - Map with Participant ID as its key, each value on the map is a ControlLoopElementDefintionMap
- * -
- -
- -
- -
- - ControlLoopElementDefintionMap
- - List of ControlLoopElementDefinition values for a particular participant, keyed by its Control
- Loop Element Definition ID
- * -
- -
- -
- -
- - ControlLoopElementDefinition
- - A ControlLoopElementToscaServiceTemplate containing the definition of the Control Loop Element
- and a CommonPropertiesMap with the values of the common property values for Control Loop Elements
- of this type
- * -
- -
- -
- -
- - ControlLoopElementToscaServiceTemplate
- - The definition of the Control Loop Element in TOSCA
- * -
- -
- -
- -
- - CommonPropertiesMap
- - A <String, String> map indexed by the property name. Each map entry is the serialized value of
- the property, which can be deserialized into an instance of the type of the property.
- * - ParticipantUpdateAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Participant Update
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantDeregister
- - Participant
- - CLAMP Runtime
- - Participant deregisters with the CLAMP runtime
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * - ParticipantDeregisterAck
- - CLAMP Runtime
- - Participant
- - Acknowledgement of Participant Deegistration
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ControlLoopUpdate
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime sends Control Loop Element instances and Instance Specific Parameter Values for
- a Control Loop Instance to Participants
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - ParticipantUpdateMap
- - Map with Participant ID as its key, each value on the map is a ControlLoopElementList
- * -
- -
- -
- -
- - ControlLoopElementList
- - List of ControlLoopElement values for the Control Loop
- * -
- -
- -
- -
- - ControlLoopElement
- - A ControlLoopElement, which contains among other things a PropertiesMap with the values of the
- property values for this Control Loop Element instance and a ToscaServiceTemplateFragment with
- extra concept definitions and instances that a participant may need.
- * -
- -
- -
- -
- - PropertiesMap
- - A <String, String> map indexed by the property name. Each map entry is the serialized value of
- the property, which can be deserialized into an instance of the type of the property.
- * -
- -
- -
- -
- - ToscaServiceTemplateFragment
- - A well-formed TOSCA service template containing extra concept definitions and instances that a
- participant may need. For example, the Policy Participant may need policy type definitions or
- policy instances to be provided if they are not already stored in the Policy Framework.
- * - ControlLoopUpdateAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Control Loop Update
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - ControlLoopResult
- - Holds a Result and Message for the overall operation on the participant and a map of Result
- and Message fields for each Control Loop Element of the control loop on this participant
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ControlLoopStateChange
- - CLAMP Runtime
- - Participant
- - CLAMP Runtime asks Participants to change the state of a Control Loop
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - currentState
- - The current state of the Control Loop
- * -
- -
- -
- -
- - orderedState
- - The state that the Control Loop should transition to
- * -
- -
- -
- -
- - startPhase
- - The start phase to which this ControLoopStateChange message applies
- * - ControlLoopStateChangeAck
- - Participant
- - CLAMP Runtime
- - Acknowledgement of Control Loop State Change
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop Type
- Definitions
- * -
- -
- -
- -
- - ControlLoopId
- - The name and version of the Control Loop
- * -
- -
- -
- -
- - startPhase
- - The start phase to which this ControLoopStateChangeAck message applies
- * -
- -
- -
- -
- - ControlLoopResult
- - Holds a Result and Message for the overall operation on the participant and a map of Result and
- Message fields for each Control Loop Element of the control loop on this participant
- * -
- -
- -
- -
- - Result
- - Success/Fail
- * -
- -
- -
- -
- - Message
- - Message indicating reason for failure
- * - ParticipantStatusReq
- - CLAMP Runtime
- - Participant
- - Request that the specified participants return a ParticipantStatus message immediately
- - ParticipantId
- - The ID of this participant, if not specified, all participants respond.
- * - ParticipantStatus
- - Participant
- - CLAMP Runtime
- - Periodic or on-demand report for heartbeat, Participant Status, Control Loop Status, and Control
- Loop Statistics
- - ParticipantId
- - The ID of this participant
- * -
- -
- -
- -
- - ParticipantType
- - The type of the participant, maps to the capabilities of the participant in Control Loop
- Type Definitions
- * -
- -
- -
- -
- - ParticipantDefinitionUpdateMap (returned in repsonse to ParticipantStatusReq only)
- - See ParticipantUpdate message above for definition of this field
- * -
- -
- -
- -
- - ParticipantStatus
- - The current status of the participant for monitoring
- * -
- -
- -
- -
- - ParticipantStatistics
- - Statistics on the participant such as up time, or messages processed. Can include participant
- specific data in a string blob that is opaque to CLAMP
- * -
- -
- -
- -
- - ControlLoopInfoMap
- - A map of ControlLoopInfo types indexed by ControlLoopId, one entry for each control loop
- running on the participant
- * -
- -
- -
- -
- - ControlLoopInfo
- - The ControlLoopStatus and ControlLoopStatistics for a given control loop
- * -
- -
- -
- -
- - ControlLoopStatus
- - The current status of the control loop for monitoring
- * -
- -
- -
- -
- - ControlLoopStatistics
- - Statistics on the control loop such as up time, or messages processed. Can include participant
- specific data in a string blob that is opaque to CLAMP
-
-
-End of Document
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _controlloop-rest-apis-label:
-
-REST APIs for CLAMP Control Loops
-#################################
-
-
-Commissioning API
-=================
-
-This API is a CRUD API that allows Control Loop Type definitions created in a design
-environment to be commissioned on the CLAMP runtime. It has endpoints that allow Control
-Loop Types to be created, read, updated, and deleted.
-
-The body of the create and update end points is a TOSCA Service/Topology template that
-defines the new or changed Control Loop Type. The update and delete endpoints take a
-reference to the Control Loop Type. The incoming TOSCA is verified and checked for
-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>`
-
-.. swaggerv2doc:: swagger/controlloop-comissioning.json
-
-
-Instantiation API
-=================
-
-The instantiation API has two functions:
-
-#. Creation, Reading, Update, and Deletion of Control Loop Instances.
-#. Instantiation and lifecycle management of Control Loop Instances on participants
-
-The Instantiation API is used by the CLAMP GUI.
-
-Instantiation Control Loop Instance CRUD
-----------------------------------------
-
-This sub API allows for the creation, read, update, and deletion of Control Loop Instances.
-The endpoints for create and update take a JSON body that describes the Control Loop Instance.
-The endpoints for read and delete take a Control Loop Instance ID to determine which Control
-Loop Instance to act on. For the delete endpoint, a check is made to ensure that the Control
-Loop Instance is not instantiated on participants.
-
-A call to the update endpoint for a Control Loop Instance follow the semantics described here:
-`4.1 Management of Control Loop Instance Configurations <management-cl-instance-configs>`.
-
-:download:`Download Policy Control Loop Instantiation API Swagger <swagger/controlloop-instantiation.json>`
-
-.. swaggerv2doc:: swagger/controlloop-instantiation.json
-
-
-Instantiation Control Loop Instance Lifecycle Management
---------------------------------------------------------
-
-This sub API is used to manage the life cycle of Control Loop Instances. A Control Loop Instance
-can be in the states described here: `2.1 Control Loop Instance States <controlloop-instance-states>`.
-Managing the life cycle of a Control Loop Instance amounts to steering the Control Loop through
-its states.
-
-The sub API allows upgrades and downgrades of Control Loop Instances to be pushed to participants
-following the semantics described here: `4.1 Management of Control Loop Instance Configurations
-<management-cl-instance-configs>`. When the API is used to update the participants on a Control
-Loop Instance, the new/upgraded/downgraded definition of the Control Loop is pushed to the
-participants. Note that the API asks the participants in a Control Loop Instance to perform the
-update, it is the responsibility of the participants to execute the update and report the result
-using the protocols described here: `CLAMP Participants <#>`_. The progress and result of an update
-can be monitored using the `Monitoring API <monitoring-api>`.
-
-The sub API also allows a state change of a Control Loop Instance to be ordered. The required state
-of the Control Loop Instance is pushed to participants in a Control Loop Instance using the API.
-Note that the API asks the participants in a Control Loop Instance to perform the state change, it
-is the responsibility of the participants to execute the state change and report the result using
-the protocols described here: CLAMP Participants. The progress and result of a state change can be
-monitored using the `Monitoring API <monitoring-api>`.
-
-.. warning::
- The Swagger for the Instantiation Lifecycle Management API will appear here.
-
-.. _monitoring-api:
-
-Monitoring API
-==============
-
-The Monitoring API allows the state and statistics of Participants, Control Loop Instances and their Control Loop Elements to be monitored. This API is used by the CLAMP GUI. The API provides filtering so that specific Participants and Control Loop Instances can be retrieved. In addition, the quantity of statistical information to be returned can be scoped.
-
-:download:`Download Policy Control Loop Monitoring API Swagger <swagger/controlloop-monitoring.json>`
-
-.. swaggerv2doc:: swagger/controlloop-monitoring.json
-
-Pass Through API
-================
-
-This API allows information to be passed to Control Loop Elements in a control loop.
-
-.. warning::
- The requirements on this API are still under discussion.
-
-.. warning::
- The Swagger for the Pass Through API will appear here.
-
-
-Participant Standalone API
-==========================
-
-This API allows a Participant to run in standalone mode and to run standalone Control Loop Elements.
-
-Kubernetes participant can also be deployed as a standalone application and provides REST end points
-for onboarding helm charts to its local chart storage, installing and uninstalling of helm charts to
-a kubernetes cluster. It also allows to configure a remote repository in kubernetes participant for
-installing helm charts. User can onboard a helm chart along with the overrides yaml file, the chart
-gets stored in to the local chart directory of kubernetes participant. The onboarded charts can be
-installed, uninstalled. The GET API fetches all the available helm charts from the chart storage.
-
-:download:`Download Policy Control Loop Participant Standalone API Swagger <swagger/k8sparticipant.json>`
-
-.. swaggerv2doc:: swagger/k8sparticipant.json
-
-
-Participant Simulator API
-=========================
-
-This API allows a Participant Simulator to be started and run for test purposes.
-
-:download:`Download Policy Participant Simulator API Swagger <swagger/participant-sim.json>`
-
-.. swaggerv2doc:: swagger/participant-sim.json
-
-End of Document
--- /dev/null
+{
+ "swagger": "2.0",
+ "info": {
+ "description": "Api Documentation",
+ "version": "1.0",
+ "title": "Api Documentation",
+ "termsOfService": "urn:tos",
+ "contact": {},
+ "license": {
+ "name": "Apache 2.0",
+ "url": "http://www.apache.org/licenses/LICENSE-2.0"
+ }
+ },
+ "paths": {
+ "/onap/automationcomposition/v2/commission": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Query details of the requested commissioned automation composition definitions",
+ "description": "Queries details of the requested commissioned automation composition definitions, returning all automation composition details",
+ "operationId": "queryUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Automation composition definition name",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Automation composition definition version",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "array",
+ "items": {
+ "$ref": "#/definitions/ToscaNodeTemplateRes",
+ "originalRef": "ToscaNodeTemplateRes"
+ }
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ },
+ "post": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Commissions automation composition definitions",
+ "description": "Commissions automation composition definitions, returning commissioned definition IDs",
+ "operationId": "createUsingPOST",
+ "consumes": [
+ "application/json",
+ "application/yaml"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "body",
+ "description": "Entity Body of Automation Composition",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/ToscaServiceTemplateReq",
+ "originalRef": "ToscaServiceTemplateReq"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/CommissioningResponse",
+ "originalRef": "CommissioningResponse"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ },
+ "delete": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Delete a commissioned automation composition",
+ "description": "Deletes a Commissioned Automation Composition, returning optional error details",
+ "operationId": "deleteUsingDELETE",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Automation composition definition name",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Automation composition definition version",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/CommissioningResponse",
+ "originalRef": "CommissioningResponse"
+ }
+ },
+ "204": {
+ "description": "No Content"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ },
+ "/onap/automationcomposition/v2/commission/elements": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Query details of the requested commissioned automation composition element definitions",
+ "description": "Queries details of the requested commissioned automation composition element definitions, returning all automation composition elements' details",
+ "operationId": "queryElementsUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Automation composition definition name",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Automation composition definition version",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "array",
+ "items": {
+ "$ref": "#/definitions/ToscaNodeTemplateRes",
+ "originalRef": "ToscaNodeTemplateRes"
+ }
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ },
+ "/onap/automationcomposition/v2/commission/getCommonOrInstanceProperties": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Query details of the requested tosca service template common or instance properties",
+ "description": "Queries details of the requested commissioned tosca service template json commonor instance properties, returning all tosca service template common or instance property details",
+ "operationId": "queryToscaServiceCommonOrInstancePropertiesUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "common",
+ "in": "query",
+ "description": "Flag, true for common properties, false for instance",
+ "required": false,
+ "type": "boolean",
+ "default": false
+ },
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Tosca service template name",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Tosca service template version",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "object",
+ "additionalProperties": {
+ "$ref": "#/definitions/ToscaNodeTemplateRes",
+ "originalRef": "ToscaNodeTemplateRes"
+ }
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ },
+ "/onap/automationcomposition/v2/commission/toscaServiceTemplateSchema": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Query details of the requested tosca service template json schema",
+ "description": "Queries details of the requested commissioned tosca service template json schema, returning all tosca service template json schema details",
+ "operationId": "queryToscaServiceTemplateJsonSchemaUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "section",
+ "in": "query",
+ "description": "Section of Template schema is desired for",
+ "required": false,
+ "type": "string",
+ "default": "all"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "string"
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ },
+ "/onap/automationcomposition/v2/commission/toscaservicetemplate": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Commissioning API"
+ ],
+ "summary": "Query details of the requested tosca service templates",
+ "description": "Queries details of the requested commissioned tosca service template, returning all tosca service template details",
+ "operationId": "queryToscaServiceTemplateUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Tosca service template name",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Tosca service template version",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "string"
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
--- /dev/null
+{
+ "swagger": "2.0",
+ "info": {
+ "description": "Api Documentation",
+ "version": "1.0",
+ "title": "Api Documentation",
+ "termsOfService": "urn:tos",
+ "contact": {},
+ "license": {
+ "name": "Apache 2.0",
+ "url": "http://www.apache.org/licenses/LICENSE-2.0"
+ }
+ },
+ "paths": {
+ "/onap/automationcomposition/v2/instantiation": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Instantiation API"
+ ],
+ "summary": "Query details of the requested automation compositions",
+ "description": "Queries details of the requested automation compositions, returning all composition details",
+ "operationId": "queryUsingGET_1",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Automation composition definition name",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Automation composition definition version",
+ "required": false,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/AutomationCompositionsRes",
+ "originalRef": "AutomationCompositionsRes"
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ },
+ "post": {
+ "tags": [
+ "Clamp Automation Composition Instantiation API"
+ ],
+ "summary": "Commissions automation composition definitions",
+ "description": "Commissions automation composition definitions, returning the automation composition IDs",
+ "operationId": "createUsingPOST_1",
+ "consumes": [
+ "application/json",
+ "application/yaml"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "automationCompositions",
+ "description": "Entity Body of automation composition",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/AutomationCompositionsReq",
+ "originalRef": "AutomationCompositionsReq"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/InstantiationResponse",
+ "originalRef": "InstantiationResponse"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ },
+ "put": {
+ "tags": [
+ "Clamp Automation Composition Instantiation API"
+ ],
+ "summary": "Updates automation composition definitions",
+ "description": "Updates automation composition definitions, returning the updated composition definition IDs",
+ "operationId": "updateUsingPUT",
+ "consumes": [
+ "application/json",
+ "application/yaml"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "automationCompositions",
+ "description": "Entity Body of Automation Composition",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/AutomationCompositionsReq",
+ "originalRef": "AutomationCompositionsReq"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/InstantiationResponse",
+ "originalRef": "InstantiationResponse"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ },
+ "delete": {
+ "tags": [
+ "Clamp Automation Composition Instantiation API"
+ ],
+ "summary": "Delete a automation composition",
+ "description": "Deletes a automation composition, returning optional error details",
+ "operationId": "deleteUsingDELETE_1",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "query",
+ "description": "Automation composition definition name",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "query",
+ "description": "Automation composition definition version",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/InstantiationResponse",
+ "originalRef": "InstantiationResponse"
+ }
+ },
+ "204": {
+ "description": "No Content"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ },
+ "/onap/automationcomposition/v2/instantiation/command": {
+ "put": {
+ "tags": [
+ "Clamp Automation Composition Instantiation API"
+ ],
+ "summary": "Issue a command to the requested automation compositions",
+ "description": "Issues a command to an automation composition, ordering a state change on the composition",
+ "operationId": "issueAutomationCompositionCommandUsingPUT",
+ "consumes": [
+ "application/json",
+ "application/yaml"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "command",
+ "description": "Entity Body of automation composition command",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/InstantiationCommand",
+ "originalRef": "InstantiationCommand"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/InstantiationResponse",
+ "originalRef": "InstantiationResponse"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Istanbul"
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
}
},
"paths": {
- "/onap/controlloop/v2/monitoring/clelement": {
+ "/onap/automationcomposition/v2/monitoring/acelement": {
"get": {
"tags": [
- "Clamp Control Loop Monitoring API"
+ "Clamp Automation Composition Monitoring API"
],
- "summary": "Query details of the requested cl element stats",
- "description": "Queries details of the requested cl element stats, returning all clElement stats",
+ "summary": "Query details of the requested acElement stats",
+ "description": "Queries details of the requested acElement stats, returning all acElement stats",
"operationId": "queryElementStatisticsUsingGET",
"produces": [
"application/json",
{
"name": "id",
"in": "query",
- "description": "Control Loop element id",
+ "description": "Automation composition element id",
"required": false,
"type": "string"
},
"200": {
"description": "OK",
"schema": {
- "$ref": "#/definitions/ClElementStatisticsList",
- "originalRef": "ClElementStatisticsList"
+ "$ref": "#/definitions/AcElementStatisticsList",
+ "originalRef": "AcElementStatisticsList"
}
},
"401": {
],
"x-interface info": {
"api-version": "1.0.0",
- "last-mod-release": "Dublin"
+ "last-mod-release": "Istanbul"
}
}
},
- "/onap/controlloop/v2/monitoring/clelements/controlloop": {
+ "/onap/automationcomposition/v2/monitoring/acelements/automationcomposition": {
"get": {
"tags": [
- "Clamp Control Loop Monitoring API"
+ "Clamp Automation Composition Monitoring API"
],
- "summary": "Query details of the requested cl element stats in a control loop",
- "description": "Queries details of the requested cl element stats, returning all clElement stats",
- "operationId": "queryElementStatisticsPerControlLoopUsingGET",
+ "summary": "Query details of the requested acElement stats in a automation composition",
+ "description": "Queries details of the requested acElement stats, returning all acElement stats",
+ "operationId": "queryElementStatisticsPerAutomationCompositionUsingGET",
"produces": [
"application/json",
"application/yaml"
{
"name": "name",
"in": "query",
- "description": "Control Loop name",
+ "description": "Automation composition name",
"required": true,
"type": "string"
},
{
"name": "version",
"in": "query",
- "description": "Control Loop version",
+ "description": "Automation composition version",
"required": true,
"type": "string"
},
"200": {
"description": "OK",
"schema": {
- "$ref": "#/definitions/ClElementStatisticsList",
- "originalRef": "ClElementStatisticsList"
+ "$ref": "#/definitions/AcElementStatisticsList",
+ "originalRef": "AcElementStatisticsList"
}
},
"401": {
],
"x-interface info": {
"api-version": "1.0.0",
- "last-mod-release": "Dublin"
+ "last-mod-release": "Istanbul"
}
}
},
- "/onap/controlloop/v2/monitoring/participant": {
+ "/onap/automationcomposition/v2/monitoring/participant": {
"get": {
"tags": [
- "Clamp Control Loop Monitoring API"
+ "Clamp Automation Composition Monitoring API"
],
"summary": "Query details of the requested participant stats",
"description": "Queries details of the requested participant stats, returning all participant stats",
{
"name": "name",
"in": "query",
- "description": "Control Loop participant name",
+ "description": "Automation composition participant name",
"required": false,
"type": "string"
},
{
"name": "version",
"in": "query",
- "description": "Control Loop participant version",
+ "description": "Automation composition participant version",
"required": false,
"type": "string"
},
],
"x-interface info": {
"api-version": "1.0.0",
- "last-mod-release": "Dublin"
+ "last-mod-release": "Istanbul"
}
}
},
- "/onap/controlloop/v2/monitoring/participants/controlloop": {
+ "/onap/automationcomposition/v2/monitoring/participants/automationcomposition": {
"get": {
"tags": [
- "Clamp Control Loop Monitoring API"
+ "Clamp Automation Composition Monitoring API"
],
- "summary": "Query details of all the participant stats in a control loop",
+ "summary": "Query details of all the participant stats in a automation composition",
"description": "Queries details of the participant stats, returning all participant stats",
- "operationId": "queryParticipantStatisticsPerControlLoopUsingGET",
+ "operationId": "queryParticipantStatisticsPerAutomationCompositionUsingGET",
"produces": [
"application/json",
"application/yaml"
{
"name": "name",
"in": "query",
- "description": "Control Loop name",
+ "description": "Automation composition name",
"required": true,
"type": "string"
},
{
"name": "version",
"in": "query",
- "description": "Control Loop version",
+ "description": "Automation composition version",
"required": true,
"type": "string"
},
],
"x-interface info": {
"api-version": "1.0.0",
- "last-mod-release": "Dublin"
+ "last-mod-release": "Istanbul"
}
}
}
+++ /dev/null
-{
- "swagger": "2.0",
- "info": {
- "description": "Api Documentation",
- "version": "1.0",
- "title": "Api Documentation",
- "termsOfService": "urn:tos",
- "contact": {},
- "license": {
- "name": "Apache 2.0",
- "url": "http://www.apache.org/licenses/LICENSE-2.0"
- }
- },
- "paths": {
- "/onap/controlloop/v2/commission": {
- "get": {
- "tags": [
- "Clamp Control Loop Commissioning API"
- ],
- "summary": "Query details of the requested commissioned control loop definitions",
- "description": "Queries details of the requested commissioned control loop definitions, returning all control loop details",
- "operationId": "queryUsingGET",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "query",
- "description": "Control Loop definition name",
- "required": false,
- "type": "string"
- },
- {
- "name": "version",
- "in": "query",
- "description": "Control Loop definition version",
- "required": false,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "type": "array",
- "items": {
- "$ref": "#/definitions/ToscaNodeTemplateRes",
- "originalRef": "ToscaNodeTemplateRes"
- }
- }
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- },
- "post": {
- "tags": [
- "Clamp Control Loop Commissioning API"
- ],
- "summary": "Commissions control loop definitions",
- "description": "Commissions control loop definitions, returning the commissioned control loop definition IDs",
- "operationId": "createUsingPOST",
- "consumes": [
- "application/json",
- "application/yaml"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "body",
- "description": "Entity Body of Control Loop",
- "required": true,
- "schema": {
- "$ref": "#/definitions/ToscaServiceTemplateReq",
- "originalRef": "ToscaServiceTemplateReq"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/CommissioningResponse",
- "originalRef": "CommissioningResponse"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- },
- "delete": {
- "tags": [
- "Clamp Control Loop Commissioning API"
- ],
- "summary": "Delete a commissioned control loop",
- "description": "Deletes a Commissioned Control Loop, returning optional error details",
- "operationId": "deleteUsingDELETE",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "query",
- "description": "Control Loop definition name",
- "required": true,
- "type": "string"
- },
- {
- "name": "version",
- "in": "query",
- "description": "Control Loop definition version",
- "required": true,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/CommissioningResponse",
- "originalRef": "CommissioningResponse"
- }
- },
- "204": {
- "description": "No Content"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- }
- },
- "/onap/controlloop/v2/commission/elements": {
- "get": {
- "tags": [
- "Clamp Control Loop Commissioning API"
- ],
- "summary": "Query details of the requested commissioned control loop element definitions",
- "description": "Queries details of the requested commissioned control loop element definitions, returning all control loop elements' details",
- "operationId": "queryElementsUsingGET",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "query",
- "description": "Control Loop definition name",
- "required": false,
- "type": "string"
- },
- {
- "name": "version",
- "in": "query",
- "description": "Control Loop definition version",
- "required": false,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "type": "array",
- "items": {
- "$ref": "#/definitions/ToscaNodeTemplateRes",
- "originalRef": "ToscaNodeTemplateRes"
- }
- }
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- }
- }
- }
-}
\ No newline at end of file
+++ /dev/null
-{
- "swagger": "2.0",
- "info": {
- "description": "Api Documentation",
- "version": "1.0",
- "title": "Api Documentation",
- "termsOfService": "urn:tos",
- "contact": {},
- "license": {
- "name": "Apache 2.0",
- "url": "http://www.apache.org/licenses/LICENSE-2.0"
- }
- },
- "paths": {
- "/onap/controlloop/v2/instantiation": {
- "get": {
- "tags": [
- "Clamp Control Loop Instantiation API"
- ],
- "summary": "Query details of the requested control loops",
- "description": "Queries details of the requested control loops, returning all control loop details",
- "operationId": "queryUsingGET_1",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "query",
- "description": "Control Loop definition name",
- "required": false,
- "type": "string"
- },
- {
- "name": "version",
- "in": "query",
- "description": "Control Loop definition version",
- "required": false,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/ControlLoopsRes",
- "originalRef": "ControlLoopsRes"
- }
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- },
- "post": {
- "tags": [
- "Clamp Control Loop Instantiation API"
- ],
- "summary": "Commissions control loop definitions",
- "description": "Commissions control loop definitions, returning the control loop IDs",
- "operationId": "createUsingPOST_1",
- "consumes": [
- "application/json",
- "application/yaml"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "controlLoops",
- "description": "Entity Body of Control Loop",
- "required": true,
- "schema": {
- "$ref": "#/definitions/ControlLoopsReq",
- "originalRef": "ControlLoopsReq"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/InstantiationResponse",
- "originalRef": "InstantiationResponse"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- },
- "put": {
- "tags": [
- "Clamp Control Loop Instantiation API"
- ],
- "summary": "Updates control loop definitions",
- "description": "Updates control loop definitions, returning the updated control loop definition IDs",
- "operationId": "updateUsingPUT",
- "consumes": [
- "application/json",
- "application/yaml"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "controlLoops",
- "description": "Entity Body of Control Loop",
- "required": true,
- "schema": {
- "$ref": "#/definitions/ControlLoopsReq",
- "originalRef": "ControlLoopsReq"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/InstantiationResponse",
- "originalRef": "InstantiationResponse"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- },
- "delete": {
- "tags": [
- "Clamp Control Loop Instantiation API"
- ],
- "summary": "Delete a control loop",
- "description": "Deletes a control loop, returning optional error details",
- "operationId": "deleteUsingDELETE_1",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "query",
- "description": "Control Loop definition name",
- "required": true,
- "type": "string"
- },
- {
- "name": "version",
- "in": "query",
- "description": "Control Loop definition version",
- "required": false,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/InstantiationResponse",
- "originalRef": "InstantiationResponse"
- }
- },
- "204": {
- "description": "No Content"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- }
- },
- "/onap/controlloop/v2/instantiation/command": {
- "put": {
- "tags": [
- "Clamp Control Loop Instantiation API"
- ],
- "summary": "Issue a command to the requested control loops",
- "description": "Issues a command to a control loop, ordering a state change on the control loop",
- "operationId": "issueControlLoopCommandUsingPUT",
- "consumes": [
- "application/json",
- "application/yaml"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "command",
- "description": "Entity Body of control loop command",
- "required": true,
- "schema": {
- "$ref": "#/definitions/InstantiationCommand",
- "originalRef": "InstantiationCommand"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/InstantiationResponse",
- "originalRef": "InstantiationResponse"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
- }
- }
- }
-}
\ No newline at end of file
{
- "swagger": "2.0",
- "info": {
- "description": "Api Documentation",
- "version": "1.0",
- "title": "Api Documentation",
- "termsOfService": "urn:tos",
- "contact": {},
- "license": {
- "name": "Apache 2.0",
- "url": "http://www.apache.org/licenses/LICENSE-2.0"
+ "swagger": "2.0",
+ "info": {
+ "description": "Api Documentation",
+ "version": "1.0",
+ "title": "Api Documentation",
+ "termsOfService": "urn:tos",
+ "contact": {},
+ "license": {
+ "name": "Apache 2.0",
+ "url": "http://www.apache.org/licenses/LICENSE-2.0"
+ }
+ },
+ "paths": {
+ "/onap/participantsim/v2/elements": {
+ "put": {
+ "tags": [
+ "Clamp Automation Composition Participant Simulator API"
+ ],
+ "summary": "Updates simulated automation composition elements",
+ "description": "Updates simulated automation composition elements, returning the updated automation composition definition IDs",
+ "operationId": "updateUsingPUT",
+ "consumes": [
+ "application/json"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "body",
+ "description": "Body of a automation composition element",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/AutomationCompositionElementReq",
+ "originalRef": "AutomationCompositionElementReq"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/TypedSimpleResponse«AutomationCompositionElement»",
+ "originalRef": "TypedSimpleResponse«AutomationCompositionElement»"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Dublin"
}
+ }
},
- "paths": {
- "/onap/participantsim/v2/elements": {
- "put": {
- "tags": [
- "Clamp Control Loop Participant Simulator API"
- ],
- "summary": "Updates simulated control loop elements",
- "description": "Updates simulated control loop elements, returning the updated control loop definition IDs",
- "operationId": "updateUsingPUT",
- "consumes": [
- "application/json"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "body",
- "description": "Body of a control loop element",
- "required": true,
- "schema": {
- "$ref": "#/definitions/ControlLoopElementReq",
- "originalRef": "ControlLoopElementReq"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/TypedSimpleResponse«ControlLoopElement»",
- "originalRef": "TypedSimpleResponse«ControlLoopElement»"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
+ "/onap/participantsim/v2/elements/{name}/{version}": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Participant Simulator API"
+ ],
+ "summary": "Query details of the requested simulated automation composition elements",
+ "description": "Queries details of the requested simulated automation composition elements, returning all automation composition element details",
+ "operationId": "elementsUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "path",
+ "description": "Automation composition element name",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "path",
+ "description": "Automation composition element version",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "object",
+ "additionalProperties": {
+ "$ref": "#/definitions/AutomationCompositionElementRes",
+ "originalRef": "AutomationCompositionElementRes"
+ }
}
- },
- "/onap/participantsim/v2/elements/{name}/{version}": {
- "get": {
- "tags": [
- "Clamp Control Loop Participant Simulator API"
- ],
- "summary": "Query details of the requested simulated control loop elements",
- "description": "Queries details of the requested simulated control loop elements, returning all control loop element details",
- "operationId": "elementsUsingGET",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "path",
- "description": "Control loop element name",
- "required": true,
- "type": "string"
- },
- {
- "name": "version",
- "in": "path",
- "description": "Control loop element version",
- "required": true,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "type": "object",
- "additionalProperties": {
- "$ref": "#/definitions/ControlLoopElementRes",
- "originalRef": "ControlLoopElementRes"
- }
- }
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
}
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
},
- "/onap/participantsim/v2/participants": {
- "put": {
- "tags": [
- "Clamp Control Loop Participant Simulator API"
- ],
- "summary": "Updates simulated participants",
- "description": "Updates simulated participants, returning the updated control loop definition IDs",
- "operationId": "updateUsingPUT_1",
- "consumes": [
- "application/json"
- ],
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "in": "body",
- "name": "body",
- "description": "Body of a participant",
- "required": true,
- "schema": {
- "$ref": "#/definitions/ParticipantReq",
- "originalRef": "ParticipantReq"
- }
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "$ref": "#/definitions/TypedSimpleResponse«Participant»",
- "originalRef": "TypedSimpleResponse«Participant»"
- }
- },
- "201": {
- "description": "Created"
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Dublin"
+ }
+ }
+ },
+ "/onap/participantsim/v2/participants": {
+ "put": {
+ "tags": [
+ "Clamp Automation Composition Participant Simulator API"
+ ],
+ "summary": "Updates simulated participants",
+ "description": "Updates simulated participants, returning the updated automation composition definition IDs",
+ "operationId": "updateUsingPUT_1",
+ "consumes": [
+ "application/json"
+ ],
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "in": "body",
+ "name": "body",
+ "description": "Body of a participant",
+ "required": true,
+ "schema": {
+ "$ref": "#/definitions/ParticipantReq",
+ "originalRef": "ParticipantReq"
+ }
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "$ref": "#/definitions/TypedSimpleResponse«Participant»",
+ "originalRef": "TypedSimpleResponse«Participant»"
+ }
+ },
+ "201": {
+ "description": "Created"
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
}
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
},
- "/onap/participantsim/v2/participants/{name}/{version}": {
- "get": {
- "tags": [
- "Clamp Control Loop Participant Simulator API"
- ],
- "summary": "Query details of the requested simulated participants",
- "description": "Queries details of the requested simulated participants, returning all participant details",
- "operationId": "participantsUsingGET",
- "produces": [
- "application/json",
- "application/yaml"
- ],
- "parameters": [
- {
- "name": "name",
- "in": "path",
- "description": "Participant name",
- "required": true,
- "type": "string"
- },
- {
- "name": "version",
- "in": "path",
- "description": "Participant version",
- "required": true,
- "type": "string"
- },
- {
- "name": "X-ONAP-RequestID",
- "in": "header",
- "description": "RequestID for http transaction",
- "required": false,
- "type": "string",
- "format": "uuid"
- }
- ],
- "responses": {
- "200": {
- "description": "OK",
- "schema": {
- "type": "array",
- "items": {
- "$ref": "#/definitions/ParticipantRes",
- "originalRef": "ParticipantRes"
- }
- }
- },
- "401": {
- "description": "Authentication Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "403": {
- "description": "Authorization Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- },
- "404": {
- "description": "Not Found"
- },
- "500": {
- "description": "Internal Server Error",
- "headers": {
- "X-LatestVersion": {
- "type": "string"
- },
- "X-PatchVersion": {
- "type": "string"
- },
- "X-MinorVersion": {
- "type": "string"
- },
- "X-ONAP-RequestID": {
- "type": "string",
- "format": "uuid"
- }
- }
- }
- },
- "security": [
- {
- "basicAuth": []
- }
- ],
- "x-interface info": {
- "api-version": "1.0.0",
- "last-mod-release": "Dublin"
- }
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Dublin"
+ }
+ }
+ },
+ "/onap/participantsim/v2/participants/{name}/{version}": {
+ "get": {
+ "tags": [
+ "Clamp Automation Composition Participant Simulator API"
+ ],
+ "summary": "Query details of the requested simulated participants",
+ "description": "Queries details of the requested simulated participants, returning all participant details",
+ "operationId": "participantsUsingGET",
+ "produces": [
+ "application/json",
+ "application/yaml"
+ ],
+ "parameters": [
+ {
+ "name": "name",
+ "in": "path",
+ "description": "Participant name",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "version",
+ "in": "path",
+ "description": "Participant version",
+ "required": true,
+ "type": "string"
+ },
+ {
+ "name": "X-ONAP-RequestID",
+ "in": "header",
+ "description": "RequestID for http transaction",
+ "required": false,
+ "type": "string",
+ "format": "uuid"
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK",
+ "schema": {
+ "type": "array",
+ "items": {
+ "$ref": "#/definitions/ParticipantRes",
+ "originalRef": "ParticipantRes"
+ }
+ }
+ },
+ "401": {
+ "description": "Authentication Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ },
+ "403": {
+ "description": "Authorization Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
}
+ },
+ "404": {
+ "description": "Not Found"
+ },
+ "500": {
+ "description": "Internal Server Error",
+ "headers": {
+ "X-LatestVersion": {
+ "type": "string"
+ },
+ "X-PatchVersion": {
+ "type": "string"
+ },
+ "X-MinorVersion": {
+ "type": "string"
+ },
+ "X-ONAP-RequestID": {
+ "type": "string",
+ "format": "uuid"
+ }
+ }
+ }
+ },
+ "security": [
+ {
+ "basicAuth": []
+ }
+ ],
+ "x-interface info": {
+ "api-version": "1.0.0",
+ "last-mod-release": "Dublin"
}
+ }
}
+ }
}
\ No newline at end of file
:depth: 4
-The CLAMP Control Loop Runtime Lifecycle Management uses the following system level dialogues.
-These dialogues enable the CLAMP runtime capabilities described in :ref:`Section 2 of
-TOSCA Defined Control Loops: Architecture and Design <controlloop-capabilities>`.
+The CLAMP Automation Composition Runtime Lifecycle Management uses the following system level
+dialogues. These dialogues enable the CLAMP runtime capabilities described in
+:ref:`Section 2 of TOSCA Defined Automation Compositions: Architecture and Design <acm-capabilities>`.
Design Time dialogues will be described in future releases of the system.
1 Commissioning Dialogues
=========================
-Commissioning dialogues are used to commission and decommission Control Loop Type definitions
-and to set the values of Common Parameters.
+Commissioning dialogues are used to commission and decommission Automation Composition Type
+definitions and to set the values of Common Parameters.
-Commissioning a Control Loop Type is a three-step process:
+Commissioning an Automation Composition Type is a three-step process:
-#. The Control Loop Type must be created, that is the Control Loop Type definition must be
- loaded and stored in the database. This step may be carried out over the REST interface or
- using SDC distribution.
+#. The Automation Composition Type must be created, that is the Automation Composition Type
+ definition must be loaded and stored in the database. This step may be carried out over the
+ REST interface or using SDC distribution.
-#. The Common Properties of the Control Loop type must be assigned values and those values
- must be stored in the database. This step is optional only if all mandatory common properties
- have default values. The Common Property values may be set and amended over and over again
- in multiple sessions until the Control Loop Type is primed.
+#. The Common Properties of the Automation Composition type must be assigned values and those
+ values must be stored in the database. This step is optional only if all mandatory common
+ properties have default values. The Common Property values may be set and amended over and
+ over again in multiple sessions until the Automation Composition Type is primed.
-#. The Control Loop Type Definition and the Common Property values must be primed, that is
- sent to the concerned participants. Once a Control Loop Type is primed, its Common Property
- values can no longer be changed. To change Common Properties on a primed Control Loop Type,
- all instances of the Control Loop Type must be removed and the Control Loop Type must be
- de-primed.
+#. The Automation Composition Type Definition and the Common Property values must be primed,
+ which is sent to the concerned participants. Once an Automation Composition Type is primed,
+ its Common Property values can no longer be changed. To change Common Properties on a primed
+ Automation Composition Type, all instances of the Automation Composition Type must be removed
+ and the Automation Composition Type must be de-primed.
-1.1 Commissioning a Control Loop Type Definition using the CLAMP GUI
---------------------------------------------------------------------
+1.1 Commissioning an Automation Composition Type Definition using the CLAMP GUI
+-------------------------------------------------------------------------------
This dialogue corresponds to a "File → Import" menu on the CLAMP GUI. The documentation of
future releases of the system will describe how the Design Time functionality interacts
.. image:: ../images/system-dialogues/comissioning-clamp-gui.png
-1.2 Commissioning a Control Loop Type Definition using SDC
-----------------------------------------------------------
+1.2 Commissioning an Automation Composition Type Definition using SDC
+---------------------------------------------------------------------
.. image:: ../images/system-dialogues/comissioning-sdc.png
-1.3 Setting Common Properties for a Control Loop Type Definition
-----------------------------------------------------------------
+1.3 Setting Common Properties for an Automation Composition 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
-definition is de-primed (See :ref:`Section 1.5 <depriming-cl-label>`).
+once an Automation Composition Type Definition and its properties are primed
+(See :ref:`Section 1.4 <priming-acm-label>`), the properties cannot be changed until the
+Automation Composition type definition is de-primed (See
+:ref:`Section 1.5 <depriming-acm-label>`).
.. image:: ../images/system-dialogues/common-properties-type-definition.png
-.. _priming-cl-label:
+.. _priming-acm-label:
-1.4 Priming a Control Loop Type Definition on Participants
-----------------------------------------------------------
-The Priming operation sends Control Loop Type definitions and common property values
-to participants. Once a Control Loop Type definition is primed, its property values
+1.4 Priming an Automation Composition Type Definition on Participants
+---------------------------------------------------------------------
+The Priming operation sends Automation Composition Type definitions and common property values
+to participants. Once an Automation Composition 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-acm-type-definition.png
-.. _depriming-cl-label:
+.. _depriming-acm-label:
-1.5 De-Prime a Control Loop Type Definition on Participants
------------------------------------------------------------
+1.5 De-Prime an Automation Composition Type Definition on Participants
+----------------------------------------------------------------------
-This dialogue allows a Control Loop Type Definition to be de-primed so that it can be
+This dialogue allows an Automation Composition 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-acm-type-definition.png
-1.6 Decommissioning a Control Loop Type Definition in CLAMP
------------------------------------------------------------
+1.6 Decommissioning an Automation Composition Type Definition in CLAMP
+----------------------------------------------------------------------
-.. image:: ../images/system-dialogues/decommission-cl-type-definition.png
+.. image:: ../images/system-dialogues/decommission-acm-type-definition.png
-1.7 Reading Commissioned Control Loop Type Definitions
-------------------------------------------------------
+1.7 Reading Commissioned Automation Composition Type Definitions
+----------------------------------------------------------------
-.. image:: ../images/system-dialogues/read-commision-cl-type-definition.png
+.. image:: ../images/system-dialogues/read-commision-acm-type-definition.png
2. Instantiation Dialogues
==========================
Instantiation dialogues are used to create, set parameters on, instantiate, update,
-and remove Control Loop instances.
+and remove Automation Composition instances.
-Assume a suitable Control Loop Definition exists in the Commissioned Control Loop Inventory.
-To get a Control Loop instance running one would, for example, execute dialogues
-:ref:`2.1 <creating-cl-instance>`, :ref:`2.3 <updating-cl-instance-config>`, and
-:ref:`2.4 <changing-cl-instance-state>`.
+Assume a suitable Automation Composition Definition exists in the Commissioned Automation
+Composition Inventory.
+To get an Automation Composition instance running one would, for example, execute dialogues
+:ref:`2.1 <creating-acm-instance>`, :ref:`2.3 <updating-acm-instance-config>`, and
+:ref:`2.4 <changing-acm-instance-state>`.
-.. _creating-cl-instance:
+.. _creating-acm-instance:
-2.1 Creating a Control Loop Instance
-------------------------------------
+2.1 Creating an Automation Composition Instance
+-----------------------------------------------
-.. image:: ../images/system-dialogues/create-cl-instance.png
+.. image:: ../images/system-dialogues/create-acm-instance.png
.. note::
- This dialogue creates the Control Loop Instance in the Instantiated Control Loop Inventory.
- The instance is sent to the participants using the process described in the dialogue in
- :ref:`Section 2.3 <updating-cl-instance-config>`.
+ This dialogue creates the Automation Composition Instance in the Instantiated Automation
+ Composition Inventory. The instance is sent to the participants using the process described
+ in the dialogue in :ref:`Section 2.3 <updating-acm-instance-config>`.
-2.2 Updating Instance Specific Parameters on a Control Loop Instance
---------------------------------------------------------------------
+2.2 Updating Instance Specific Parameters on an Automation Composition Instance
+-------------------------------------------------------------------------------
-.. image:: ../images/system-dialogues/update-instance-params-cl.png
+.. image:: ../images/system-dialogues/update-instance-params-acm.png
-.. _updating-cl-instance-config:
+.. _updating-acm-instance-config:
-2.3 Updating a Control Loop Instance with a Configuration on Participants
--------------------------------------------------------------------------
+2.3 Updating an Automation Composition Instance with a Configuration on Participants
+------------------------------------------------------------------------------------
-.. image:: ../images/system-dialogues/update-cl-instance-config-participants.png
+.. image:: ../images/system-dialogues/update-acm-instance-config-participants.png
-.. _changing-cl-instance-state:
+.. _changing-acm-instance-state:
-2.4 Changing the state of a Control Loop Instance on Participants
------------------------------------------------------------------
+2.4 Changing the state of an Automation Composition Instance on Participants
+----------------------------------------------------------------------------
-.. image:: ../images/system-dialogues/change-cl-instance-state-participants.png
+.. image:: ../images/system-dialogues/change-acm-instance-state-participants.png
-2.5 De-instantiating a Control Loop Instance from Participants
---------------------------------------------------------------
+2.5 De-instantiating an Automation Composition Instance from Participants
+-------------------------------------------------------------------------
-.. image:: ../images/system-dialogues/deinstantiate-cl-from-participants.png
+.. image:: ../images/system-dialogues/deinstantiate-acm-from-participants.png
-2.6 Deleting a Control Loop Instance
-------------------------------------
+2.6 Deleting an Automation Composition Instance
+-----------------------------------------------
-.. image:: ../images/system-dialogues/delete-cl-instance.png
+.. image:: ../images/system-dialogues/delete-acm-instance.png
-2.7 Reading Control Loop Instances
-----------------------------------
+2.7 Reading Automation Composition Instances
+--------------------------------------------
-.. image:: ../images/system-dialogues/read-cl-instance.png
+.. image:: ../images/system-dialogues/read-acm-instance.png
-1. Monitoring Dialogues
+3. Monitoring Dialogues
=======================
-Monitoring dialogues are used to monitor and to read statistics on Control Loop Instances.
+Monitoring dialogues are used to monitor and to read statistics on Automation Composition Instances.
3.1 Reporting of Monitoring Information and Statistics by Participants
----------------------------------------------------------------------
4. Supervision Dialogues
========================
-Supervision dialogues are used to check the state of Control Loop Instances and Participants.
+Supervision dialogues are used to check the state of Automation Composition Instances and
+Participants.
4.1 Supervise Participants
--------------------------
.. image:: ../images/system-dialogues/supervise-participants.png
-4.2 Supervise Control Loops
----------------------------
+4.2 Supervise Automation Compositions
+-------------------------------------
-.. image:: ../images/system-dialogues/supervise-controlloops.png
+.. image:: ../images/system-dialogues/supervise-acms.png
End of Document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-policy-gui-label:
+
+TOSCA Policy GUI
+################
+
+.. contents::
+ :depth: 4
+
+1 - How to run the Front-End Gui
+================================
+This section describes how to run the front end on your local machine.
+
+**Prerequisite:**
+
+**Building and running CLAMP**
+
+see `Clamp ACM Smoke Tests <https://docs.onap.org/projects/onap-policy-parent/en/latest/development/devtools/clamp-smoke.html>`__
+
+**Step 1:** Go to the clamp directory
+
+.. code-block:: bash
+
+ cd /clamp/extra/bin-for-dev
+
+**Step 2:** Inside the clamp directory run
+
+.. code-block:: bash
+
+ ./start-db.sh test
+
+**Step 3:** Check docker container id
+
+.. code-block:: bash
+
+ docker ps
+
+**Step 4:** Log into docker container
+
+.. code-block:: bash
+
+ docker exec -it 'container_id' bash
+
+**Step 5:** Go into mariadb shell
+
+.. code-block:: bash
+
+ mysql -u root -p
+
+**Step 6:** Enter password
+
+ strong_pitchou
+
+.. image:: images/01-gui.png
+
+**Step 7:** Go into cldsdb4 database
+
+.. code-block:: bash
+
+ use cldsdb4;
+
+**Step 8:** Verify if there is data in the following table 'loop_templates'
+
+.. code-block:: bash
+
+ select * from loop_templates;
+
+** If for some reason the database is empty do the go to the '/docker-entrypoint-initdb.d/dump' directory
+
+.. code-block:: bash
+
+ ./load-fake-data.sh
+
+**Step 9:** Once the database is up and running need to start the clamp emulator, by running the following command inside the /clamp/extra/bin-for-dev
+
+.. code-block:: bash
+
+ ./start-emulator.sh
+
+**Step 10:** Verify if mariadb and the emulator is running
+
+.. code-block:: bash
+
+ docker ps
+
+.. image:: images/02-gui.png
+
+**Step 11:** Start the backend service by running the command inside the /clamp/extra/bin-for-dev
+
+.. code-block:: bash
+
+ ./start-backend.sh
+
+
+.. _building-ui-label:
+
+2 - Checking out and building the UI
+====================================
+
+.. _Building UI
+
+**Step 1:** Checkout the UI from the repo
+
+.. code-block:: bash
+
+ git clone "https://gerrit.nordix.org/onap/policy/gui"
+
+**Step 2:** Change into the "gui" directory and run the following
+
+.. code-block:: bash
+
+ mvn clean install
+
+**Step 3:** Go into the gui-clamp/ui-react directory and run the following
+
+.. code-block:: bash
+
+ npm install
+
+**Step 4:** Start the front end UI
+
+.. code-block:: bash
+
+ npm start --scripts-prepend-node-path
+
+** If you get the following error
+
+.. image:: images/03-gui.png
+
+ gedit package.json
+
+.. code-block:: bash
+
+ change the following
+ "version": "${project.version}",
+
+ to
+
+ "version": "2.1.1",
+
+ save and close
+
+ then delete the node_modules directory
+
+ rm -rf node_modules/
+
+ then run again
+
+ npm install
+
+.. code-block:: bash
+
+ npm start --scripts-prepend-node-path
+
+**Step 5:** Once the UI starts at localhost:3000 it will ask for credentials:
+
+ Login: admin
+ Password: password
+
+3 - How to Commission/Decommission the TOSCA Service Template
+=============================================================
+
+This section describes how to commission and decommission the Tosca Service Template
+
+** Prerequisite:
+
+see clamp-policy-gui-label_
+
+**Step 1:** From the Main Menu Click on TOSCA Automation Composition Dropdown
+
+.. image:: images/04-gui.png
+
+**Step 2:** From the Dropdown Menu Select Upload Automation Composition To Commissioning
+
+.. image:: images/05-gui.png
+
+**Step 3:** On the window Upload Tosca to Commissioning API Click on the input box that says 'Please Select a file'
+
+.. image:: images/06-gui.png
+
+**Step 4:** Once the yaml file is selected click on Upload Tosca Service Template
+
+.. image:: images/07-gui.png
+
+**Step 5:** After the upload there should have a message "Upload Success" in green
+
+.. image:: images/08-gui.png
+
+**Step 6:** To validate that the TOSCA Service Template has been commissioned click on Manage Commissioned Automation Composition Template
+
+.. image:: images/09-gui.png
+
+**Step 7:** In the View Tosca Template Window click on Pull Tosca Service Template
+
+.. image:: images/10-gui.png
+
+**Step 8:** Once the Tosca Service Template has been pulled there should be a json object rendered in the window
+
+.. image:: images/11-gui.png
+
+**Step 9:** Click on Close close the window
+
+**Step 10:** Click on Edit Automation Composition Properties
+
+.. image:: images/12-gui.png
+
+**Step 11:** In the Change ACM Common Properties change the appropriate properties and click on save and there should have a popup saying 'Changes Saved. Commission When Ready...'
+
+.. image:: images/13-gui.png
+
+**Step 12:** After saving the changes click on Commission and should have a Green message saying 'Commissioning Success'
+
+.. image:: images/14-gui.png
+
+**Step 13:** To Decommission the Tosca Service Follow Step 6 and 8
+
+**Step 14:** Once the json objected is rendered in the window click on delete
+
+.. image:: images/11-gui.png
+
+**Step 14:** Once the json objected is rendered in the window click on delete
+
+.. image:: images/11-gui.png
+
+**Step 15:** If the delete is successful it should show a message "Delete Successful"
+
+.. image:: images/15-gui.png
+
+4 - How to Save Instance Properties and Change The Order State
+==============================================================
+
+This section describes how to save the instance properties and change it's order state
+
+** Prerequisite:
+
+see building-ui-label_
+
+**Step 1:** Go to the participant http directory
+
+.. code-block:: bash
+
+ cd /clamp/participant/participant-impl/participant-impl-http
+
+**Step 2:** Run he following command
+
+.. code-block:: bash
+
+ mvn spring-boot:run -Dspring-boot.run.arguments=--server.port=8080
+
+**Step 3:** Go to the participant kubernetes directory
+
+.. code-block:: bash
+
+ cd /clamp/participant/participant-impl/participant-impl-kubernetes
+
+**Step 4:** Run he following command
+
+.. code-block:: bash
+
+ mvn spring-boot:run -Dspring-boot.run.arguments=--server.port=8081
+
+**Step 5:** Go to the participant policy directory
+
+.. code-block:: bash
+
+ cd /clamp/participant/participant-impl/participant-impl-policy
+
+**Step 6:** Run he following command
+
+.. code-block:: bash
+
+ mvn spring-boot:run -Dspring-boot.run.arguments=--server.port=8082
+
+**Step 7:** From the Main Menu Click on Instantiation Management
+
+.. image:: images/16-gui.png
+
+**Step 8:** Once the window for Manage Instance is open click on Create Instance
+
+.. image:: images/17-gui.png
+
+**Step 9:** With the Window Create Instance Properties Insert a Name and change the appropriate properties and click save
+
+.. image:: images/18-gui.png
+
+**Step 10:** After clicking save it should come with a green message saying "Instantiation Properties Success"
+
+.. image:: images/19-gui.png
+
+**Step 11:** To delete an instance repeat Step 7
+
+.. image:: images/16-gui.png
+
+**Step 12:** Once the window for Manage Instance is open click on Delete
+
+.. image:: images/20-gui.png
+
+* NOTE: The only way to delete the instance properties if the order state has to be UNINITIALISED
+
+**Step 13:** To change the state click on Change in Manage Instances Window
+
+.. image:: images/20-gui.png
+
+**Step 14:** After clicking Change there should have a drop down with specific different ordered states
+
+.. image:: images/21-gui.png
+
+**Step 15:** From UNINITIALISED the user can only select Passive Ordered State
+
+.. image:: images/22-gui.png
+
+**Step 16:** Click on Save and a Message in Green "Ordered State Change Success"
+
+.. image:: images/23-gui.png
+
+* NOTE: Can't change from Passive to Running in a local developer machine, can only change in the production environment
\ No newline at end of file
+++ /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-runtime-acm>`
-#. :ref:`CLAMP Control Loop Participants <clamp-controlloop-participants>`
-#. :ref:`Managing Control Loops using The CLAMP GUI <clamp-gui-controlloop>`
-
-End of Document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _defining-acms-label:
+
+Defining Automation Compositions in TOSCA for CLAMP
+###################################################
+
+
+.. contents::
+ :depth: 4
+
+
+A Automation Composition Type is defined in a TOSCA service template. A TOSCA Service Template has
+two parts: a definition part in the service template itself, which contains the definitions
+of concepts that can be used to define the types of concepts that can appear on a Toplogy
+Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA
+<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page
+for more details on TOSCA.
+
+Unsurprisingly, to define a Automation Composition Type in TOSCA, of Automation Composition related concepts
+that we can use in all automation compositions exist. They are described in Section 1. Section 2
+describes how properties are managed. Properties are the configuration parameters that are
+provided to Automation Compositions and the Automation Composition Elements they use. Section 3 describes how to
+define a Automation Composition using the predefined Automation Composition concepts.
+
+
+1 Standard TOSCA Service Template Concepts for Automation Compositions
+======================================================================
+
+These concepts are the base concepts available to users who write definitions for automation
+compositions in TOSCA. TOSCA automation composition definitions are written using these concepts.
+
+1.1 Fundamental TOSCA Concepts for Automation Compositions
+----------------------------------------------------------
+
+The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for
+defining automation compositions.
+
+.. image:: images/defining-acms/fundamental-concepts.png
+
+The TOSCA concepts above may be declared in the TOSCA Service Template of a automation composition.
+If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they
+may be omitted from a TOSCA service template that defines a automation composition type.
+
+The *start_phase* is a value indicating the start phase in which this automation composition element
+will be started, the first start phase is zero. Automation Composition Elements are started in their
+start_phase order and stopped in reverse start phase order. Automation Composition Elements with the
+same start phase are started and stopped simultaneously.
+
+The Yaml file that holds the Definition of `TOSCA fundamental Automation Composition Types is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+and is the canonical definition of the Automation Composition concepts.
+
+1.2 TOSCA Concepts for Automation Composition Elements delivered by ONAP
+------------------------------------------------------------------------
+
+TOSCA Standard Automation Composition Elements
+
+.. image:: images/defining-acms/standard-acme.png
+ :width: 600
+
+1.2.1 Policy Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Policy Participant runs Policy Automation Composition Elements. Each Policy Automation Composition Element
+manages the deployment of the policy specified in the Policy Automation Composition Element definition.
+The Yaml file that holds the `Policy Automation Composition Element Type definition is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the Policy Automation Composition Element type. For a description of
+the Policy Automation Composition Element and Policy Participant, please see `The CLAMP Policy Framework
+Participant <#>`_ page.
+
+1.2.2 HTTP Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The HTTP Participant runs HTTP Automation Composition Elements. Each HTTP Automation Composition Element manages
+REST communication towards a REST endpoint using the REST calls a user has specified in the
+configuration of the HTTP Automation Composition Element. The Yaml file that holds the
+`HTTP Automation Composition Element Type definition is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the HTTP Automation Composition Element type. For a description of
+the HTTP Automation Composition Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page.
+
+.. _kubernetes-acm-element:
+
+1.2.3 Kubernetes Automation Composition Element
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Kubernetes Participant runs Kubernetes Automation Composition Elements. Each Kubernetes Automation Composition
+Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the
+Kubernetes microservice as well as other properties that the microservice requires in order to
+execute. The Yaml file that holds the
+`Kubernetes Automation Composition Element Type defintion is available in Github
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesAutomationCompositionElementType.yaml>`_
+and is the canonical definition of the Kubernetes Automation Composition Element type. For a description
+of the Kubernetes Automation Composition Element and Kubernetes Participant,please see
+`The CLAMP Kubernetes Participant <#>`_ page.
+
+
+2 Common and Instance Specific Properties
+=========================================
+
+Properties are used to define the configuration for Automation Compositions and Automation Composition Elements.
+At design time, the types, constraints, and descriptions of the properties are specified.
+The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support
+for defining properties, see `Section 3.6.10: TOSCA Property Definition
+<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_
+in the TOSCA documentation.
+
+2.1 Terminology for Properties
+------------------------------
+
+**Property:** Metadata defined in TOSCA that is associated with a Automation Composition, a Automation
+Composition Element, or a Participant.
+
+**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have
+a generic type such as string or integer or can have a user defined TOSCA data type.
+
+**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run
+time in CLAMP.
+
+**Common Property Type:** Property Types that apply to all instances of a Automation Composition Type.
+
+**Common Property Value:** The value of a Property Type. It is assigned at run time once for
+all instances of a Automation Composition Type.
+
+**Instance Specific Property Type:** Property Types that apply to an individual instance of
+a Automation Composition Type.
+
+**Instance Specific Property Value:** The value of a Property Type that applies to an
+individual instance of a Automation Composition Type. The value is assigned at run time for each
+automation composition instance.
+
+Automation Composition Properties can be *common* or *instance specific*. See Section 2 of
+:ref:`TOSCA Defined Automation Compositions: Architecture and Design <acm-capabilities>`
+for a detailed description of the usage of common and instance specific properties.
+
+2.2 Common Properties
+---------------------
+
+Common properties apply to all instances of a automation composition. Common properties are identified
+by a special metadata flag in Automation Composition and Automation Composition Element definitions. For example,
+the startPhase parameter on any Automation Composition Element has the same value for any instance of
+that automation composition element, so it is defined as shown below in the
+`Definition of TOSCA fundamental Automation Composition Types
+<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/AutomationCompositionTOSCAServiceTemplateTypes.yaml>`_
+yaml file.
+
+.. code-block:: yaml
+
+ startPhase:
+ type: integer
+ required: false
+ constraints:
+ - greater-or-equal: 0
+ description: A value indicating the start phase in which this automation composition element will be started, the
+ first start phase is zero. Automation Composition Elements are started in their start_phase order and stopped
+ in reverse start phase order. Automation Composition Elements with the same start phase are started and
+ stopped simultaneously
+ metadata:
+ common: true
+
+The "common: true" value in the metadata of the startPhase property identifies that property
+as being a common property. This property will be set on the CLAMP GUI during automation composition
+commissioning.
+
+2.3 Instance Specific Properties
+--------------------------------
+
+Instance Specific properties apply to individual instances of a Automation Composition and/or Automation
+Composition Element and must be set individually for Automation Composition and Automation Composition Element instance.
+Properties are instance specific by default, but can be identified by a special metadata flag
+in Automation Composition and Automation Composition Element definitions. For example, the chart parameter on a
+Kubernetes Automation Composition Element has a different value for every instance of a Kubernetes Automation
+Composition Element, so it can be defined as shown below in the :ref:`Kubernetes Automation Composition Type definition
+<kubernetes-acm-element>` yaml file.
+
+
+.. code-block:: yaml
+
+ # Definition that omits the common flag metadata
+ chart:
+ type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart
+ typeVersion: 1.0.0
+ description: The helm chart for the microservice
+ required: true
+
+ # Definition that specifies the common flag metadata
+ chart:
+ type: org.onap.datatypes.policy.clamp.acm.kubernetesAutomationCompositionElement.Chart
+ typeVersion: 1.0.0
+ description: The helm chart for the microservice
+ required: true
+ metadata:
+ common: false
+
+The "common: false" value in the metadata of the chart property identifies that property as
+being an instance specific property. This property will be set on the CLAMP GUI during automation
+composition instantiation.
+
+
+3 Writing a Automation Composition Type Definition
+==================================================
+
+The TOSCA definition of a automation composition contains a TOSCA Node Template for the automation composition
+itself, which contains TOSCA Node Templates for each Automation Composition Element that makes up the
+Automation Composition.
+
+.. image:: images/defining-acms/acm-node-template.png
+ :width: 600
+
+To create a automation composition, a user creates a TOSCA Topology Template. In the Topology Template,
+the user creates a TOSCA Node Template for each Automation Composition Element that will be in the
+Automation Composition Definition. Finally, the user creates the Node Template that defines the Automation
+Composition itself, and references the Automation Composition Element definitions that make up the Automation Composition
+Definition.
+
+3.1 The Gentle Guidance Automation Composition
+----------------------------------------------
+
+The best way to explain how to create a Automation Composition Definition is by example.
+
+.. image:: images/defining-acms/gentle-guidance-acm.png
+
+The example Gentle Guidance automation composition is illustrated in the diagram above. The domain logic for the automation composition is
+implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice
+over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance automation composition using
+our TOSCA based Automation Composition Life Cycle Management approach. To do this we create four Automation Composition Element definitions,
+one for the Kubernetes microservice, one for the policy and one or the REST configuration.
+
+3.2 The TOSCA Automation Composition Definition
+-----------------------------------------------
+
+We use a TOSCA Topology Template to specify a Automation Composition definition and the definitions of
+its Automation Composition Elements. Optionally, we can specify default parameter values in the TOSCA
+Topology Template. The actual values of Automation Composition common and instance specific parameters
+are set at run time in the CLAMP GUI.
+
+In the case of the Gentle Guidance automation composition, we define a Automation Composition Element Node Template
+for each part of the domain logic we are managing. We then define the Automation Composition Node Template
+for the automation composition itself.
+
+Please refer to the `No Properties yaml file in Github
+<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceNoProperties.yaml>`_
+for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
+domain when no parameters are defined.
+
+Please refer to the `Default Properties yaml file in Github
+<https://github.com/onap/policy-clamp/blob/cbd4d5dbe88928d5765e9749987f6b93f2b347e9/examples/src/main/resources/clamp/acm/gentleguidance/GentleGuidanceDefaultProperties.yaml>`_
+for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
+domain when the default values of parameters are defined.
+
+
+4 Creating Custom Automation Composition Elements
+=================================================
+
+Any organization can include their own component in the framework and use the framework and have
+the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a
+Automation Composition. To do this, a participant for the component must be developed that allows Automation
+Composition Elements for that component to be run. To develop a participant, the participant must comply
+with the `CLAMP Participants <#>`_
+framework and in particular comply with `The CLAMP Automation Composition Participant Protocol <#>`_.
+The organization must also specify a new Automation Composition Element type definition in TOSCA similar to
+those supplied in ONAP and described in Section 1.2. This Automation Composition Element type tells the
+CLAMP Automation Composition Lifecycle management that the Automation Composition Element exists and can be included
+in automation compositions. It also specifies the properties that can be specified for the Automation Composition Element.
+
+An organization can supply the code for the Participant (for example as a Java jar file) and a
+TOSCA artifact with the Automation Composition Element definition and it can be added to the platform. In
+future releases, support will be provided to include participants and their Automation Composition Element
+definitions as packaged plugins that can be installed on the platform.
+
+End of document
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _defining-controlloops-label:
-
-Defining Control Loops in TOSCA for CLAMP
-#########################################
-
-
-.. contents::
- :depth: 4
-
-
-A Control Loop Type is defined in a TOSCA service template. A TOSCA Service Template has
-two parts: a definition part in the service template itself, which contains the definitions
-of concepts that can be used to define the types of concepts that can appear on a Toplogy
-Template and a Topology Template that defines a topology. See the `Oasis Open TOSCA
-<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/>`_ web page
-for more details on TOSCA.
-
-Unsurprisingly, to define a Control Loop Type in TOSCA, of Control Loop related concepts
-that we can use in all control loops exist. They are described in Section 1. Section 2
-describes how properties are managed. Properties are the configuration parameters that are
-provided to Control Loops and the Control Loop Elements they use. Section 3 describes how to
-define a Control Loop using the predefined Control Loop concepts.
-
-
-1 Standard TOSCA Service Template Concepts for Control Loops
-============================================================
-
-These concepts are the base concepts available to users who write definitions for control
-loops in TOSCA. TOSCA control loop definitions are written using these concepts.
-
-1.1 Fundamental TOSCA Concepts for Control Loops
-------------------------------------------------
-
-The following TOSCA concepts are the fundamental concepts in a TOSCA Service Template for
-defining control loops.
-
-.. image:: images/defining-controlloops/fundamental-concepts.png
-
-The TOSCA concepts above may be declared in the TOSCA Service Template of a control loop.
-If the concepts already exist in the Design Time Catalogue or the Runtime Inventory, they
-may be omitted from a TOSCA service template that defines a control loop type.
-
-The *start_phase* is a value indicating the start phase in which this control loop element
-will be started, the first start phase is zero. Control Loop Elements are started in their
-start_phase order and stopped in reverse start phase order. Control Loop Elements with the
-same start phase are started and stopped simultaneously.
-
-The Yaml file that holds the Definition of `TOSCA fundamental Control Loop Types is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-and is the canonical definition of the Control Loop concepts.
-
-1.2 TOSCA Concepts for Control Loop Elements delivered by ONAP
---------------------------------------------------------------
-
-TOSCA Standard Control Loop Elements
-
-.. image:: images/defining-controlloops/standard-cle.png
- :width: 600
-
-1.2.1 Policy Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Policy Participant runs Policy Control Loop Elements. Each Policy Control Loop Element
-manages the deployment of the policy specified in the Policy Control Loop Element definition.
-The Yaml file that holds the `Policy Control Loop Element Type definition is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/PolicyControlLoopElementType.yaml>`_
-and is the canonical definition of the Policy Control Loop Element type. For a description of
-the Policy Control Loop Element and Policy Participant, please see `The CLAMP Policy Framework
-Participant <#>`_ page.
-
-1.2.2 HTTP Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The HTTP Participant runs HTTP Control Loop Elements. Each HTTP Control Loop Element manages
-REST communication towards a REST endpoint using the REST calls a user has specified in the
-configuration of the HTTP Control Loop Element. The Yaml file that holds the
-`HTTP Control Loop Element Type definition is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/HttpControlLoopElementType.yaml>`_
-and is the canonical definition of the HTTP Control Loop Element type. For a description of
-the HTTP Control Loop Element and HTTP Participant, please see `The CLAMP HTTP Participant <#>`_ page.
-
-.. _kubernetes-cl-element:
-
-1.2.3 Kubernetes Control Loop Element
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Kubernetes Participant runs Kubernetes Control Loop Elements. Each Kubernetes Control Loop
-Element manages a Kubernetes microservice using Helm. The user defines the Helm chart for the
-Kubernetes microservice as well as other properties that the microservice requires in order to
-execute. The Yaml file that holds the
-`Kubernetes Control Loop Element Type defintion is available in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/KubernetesControlLoopElementType.yaml>`_
-and is the canonical definition of the Kubernetes Control Loop Element type. For a description
-of the Kubernetes Control Loop Element and Kubernetes Participant,please see
-`The CLAMP Kubernetes Participant <#>`_ page.
-
-
-2 Common and Instance Specific Properties
-=========================================
-
-Properties are used to define the configuration for Control Loops and Control Loop Elements.
-At design time, the types, constraints, and descriptions of the properties are specified.
-The values for properties are specified in the CLAMP GUI at runtime. TOSCA provides support
-for defining properties, see `Section 3.6.10: TOSCA Property Definition
-<https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_DEFN>`_
-in the TOSCA documentation.
-
-2.1 Terminology for Properties
-------------------------------
-
-**Property:** Metadata defined in TOSCA that is associated with a Control Loop, a Control
-Loop Element, or a Participant.
-
-**TOSCA Property Type:** The TOSCA definition of the type of a property. A property can have
-a generic type such as string or integer or can have a user defined TOSCA data type.
-
-**TOSCA Property Value:** The value of a Property Type. Property values are assigned at run
-time in CLAMP.
-
-**Common Property Type:** Property Types that apply to all instances of a Control Loop Type.
-
-**Common Property Value:** The value of a Property Type. It is assigned at run time once for
-all instances of a Control Loop Type.
-
-**Instance Specific Property Type:** Property Types that apply to an individual instance of
-a Control Loop Type.
-
-**Instance Specific Property Value:** The value of a Property Type that applies to an
-individual instance of a Control Loop Type. The value is assigned at run time for each
-control loop instance.
-
-Control Loop Properties can be *common* or *instance specific*. See Section 2 of
-:ref:`TOSCA Defined Control Loops: Architecture and Design <controlloop-capabilities>`
-for a detailed description of the usage of common and instance specific properties.
-
-2.2 Common Properties
----------------------
-
-Common properties apply to all instances of a control loop. Common properties are identified
-by a special metadata flag in Control Loop and Control Loop Element definitions. For example,
-the startPhase parameter on any Control Loop Element has the same value for any instance of
-that control loop element, so it is defined as shown below in the
-`Definition of TOSCA fundamental Control Loop Types
-<https://github.com/onap/policy-clamp/blob/master/common/src/main/resources/tosca/ControlLoopTOSCAServiceTemplateTypes.yaml>`_
-yaml file.
-
-.. code-block:: yaml
-
- startPhase:
- type: integer
- required: false
- constraints:
- - greater-or-equal: 0
- description: A value indicating the start phase in which this control loop element will be started, the
- first start phase is zero. Control Loop Elements are started in their start_phase order and stopped
- in reverse start phase order. Control Loop Elements with the same start phase are started and
- stopped simultaneously
- metadata:
- common: true
-
-The "common: true" value in the metadata of the startPhase property identifies that property
-as being a common property. This property will be set on the CLAMP GUI during control loop
-commissioning.
-
-2.3 Instance Specific Properties
---------------------------------
-
-Instance Specific properties apply to individual instances of a Control Loop and/or Control
-Loop Element and must be set individually for Control Loop and Control Loop Element instance.
-Properties are instance specific by default, but can be identified by a special metadata flag
-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.
-
-
-.. code-block:: yaml
-
- # Definition that omits the common flag metadata
- chart:
- type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
- typeVersion: 1.0.0
- description: The helm chart for the microservice
- required: true
-
- # Definition that specifies the common flag metadata
- chart:
- type: org.onap.datatypes.policy.clamp.controlloop.kubernetesControlLoopElement.Chart
- typeVersion: 1.0.0
- description: The helm chart for the microservice
- required: true
- metadata:
- common: false
-
-The "common: false" value in the metadata of the chart property identifies that property as
-being an instance specific property. This property will be set on the CLAMP GUI during control
-loop instantiation.
-
-
-3 Writing a Control Loop Type Definition
-=========================================
-
-The TOSCA definition of a control loop contains a TOSCA Node Template for the control loop
-itself, which contains TOSCA Node Templates for each Control Loop Element that makes up the
-Control Loop.
-
-.. image:: images/defining-controlloops/controlloop-node-template.png
- :width: 600
-
-To create a control loop, a user creates a TOSCA Topology Template. In the Topology Template,
-the user creates a TOSCA Node Template for each Control Loop Element that will be in the
-Control Loop Definition. Finally, the user creates the Node Template that defines the Control
-Loop itself, and references the Control Loop Element definitions that make up the Control Loop
-Definition.
-
-3.1 The Gentle Guidance Control Loop
-------------------------------------
-
-The best way to explain how to create a Control Loop Definition is by example.
-
-.. image:: images/defining-controlloops/gentle-guidance-controlloop.png
-
-The example Gentle Guidance control loop is illustrated in the diagram above. The domain logic for the control loop is
-implemented in a microservice running in Kubernetes, a policy, and some configuration that is passed to the microservice
-over a REST endpoint. We want to manage the life cycle of the domain logic for our Gentle Guidance control loop using
-our TOSCA based Control Loop Life Cycle Management approach. To do this we create four Control Loop Element definitions,
-one for the Kubernetes microservice, one for the policy and one or the REST configuration.
-
-3.2 The TOSCA Control Loop Definition
--------------------------------------
-
-We use a TOSCA Topology Template to specify a Control Loop definition and the definitions of
-its Control Loop Elements. Optionally, we can specify default parameter values in the TOSCA
-Topology Template. The actual values of Control Loop common and instance specific parameters
-are set at run time in the CLAMP GUI.
-
-In the case of the Gentle Guidance control loop, we define a Control Loop Element Node Template
-for each part of the domain logic we are managing. We then define the Control Loop Node Template
-for the control loop itself.
-
-Please refer to the `No Properties yaml file in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceNoPropeties.yaml>`_
-for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
-domain when no parameters are defined.
-
-Please refer to the `Default Properties yaml file in Github
-<https://github.com/onap/policy-clamp/blob/master/common/src/test/resources/gentleguidance/GentleGuidanceDefaultPropeties.yaml>`_
-for the definitive Yaml specification for the TOSCA Topology Template for the Gentle Guidance
-domain when the default values of parameters are defined.
-
-
-4 Creating Custom Control Loop Elements
-========================================
-
-Any organization can include their own component in the framework and use the framework and have
-the Policy Framework CLAMP manage the lifecycle of domain logic in their component as part of a
-Control Loop. To do this, a participant for the component must be developed that allows Control
-Loop Elements for that component to be run. To develop a participant, the participant must comply
-with the `CLAMP Participants <#>`_
-framework and in particular comply with `The CLAMP Control Loop Participant Protocol <#>`_.
-The organization must also specify a new Control Loop Element type definition in TOSCA similar to
-those supplied in ONAP and described in Section 1.2. This Control Loop Element type tells the
-CLAMP Control Loop Lifecycle management that the Control Loop Element exists and can be included
-in control loops. It also specifies the properties that can be specified for the Control Loop Element.
-
-An organization can supply the code for the Participant (for example as a Java jar file) and a
-TOSCA artifact with the Control Loop Element definition and it can be added to the platform. In
-future releases, support will be provided to include participants and their Control Loop Element
-definitions as packaged plugins that can be installed on the platform.
-
-End of document
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+
+.. _clamp-gui-acm:
+
+The Policy GUI for Automation Compositions
+******************************************
+
+.. contents::
+ :depth: 4
+
+.. _Introduction:
+
+1. Introduction
+###############
+The Policy GUI for Automation Compositions is designed to provide a user the ability to interact with the Automation Composition Runtime to perform several actions. The actual technical design of the Automation Composition Runtime is detailed in :ref:`clamp-runtime-acm`. All of the endpoints and the purpose for accessing those endpoints is discussed there. In the current release of the GUI, the main purposes are to perform the below:
+
+- Commission new Tosca Service Templates.
+- Editing Common Properties.
+- Priming/De-priming Automation Composition Definitions.
+- Decommission existing Tosca Service Templates.
+- Create new instances of Automation Compositions.
+- Change the state of the Automation Compositions.
+- Delete Automation Compositions.
+
+These functions can be carried out by accessing the Automation Composition Runtime alone but this should not be required for a typical user to access the system. That is why the Automation Composition GUI is required. The remainder of this document will be split into 2 main sections. The first section will show the overall architecture of Automation Composition with the GUI included, so that the reader can see where it fits in to the system. Then the section will outline the individual components required for a working GUI and outline how GUI interacts with these components and why. The final section has a diagram to show the flow of typical operations from the GUI, all the way down to the participants.
+
+2. GUI-focussed System Architecture
+###################################
+An architectural/functional diagram has bee provided in below. This does not show details of the other components involved in the GUI functionality. Most of the detail is provided for the GUI itself.
+
+ .. image:: ../images/gui/GUI-Architecture.png
+ :align: center
+
+The remainder of this section outlines the different elements that comprise the architecture of the GUI and how the different elements connect to one another.
+
+2.1 Policy CLAMP GUI
+--------------------
+
+2.1.1 CLAMP GUI
+================
+The original Clamp project used the GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Connection to all of these services is managed by the Camel Exchange present in the section :ref:`Policy Clamp Backend`.
+
+Class-based react components are used to render the different pages related to functionality around
+
+- Creating loop instances from existing templates that have been distributed by SDC.
+- Deploying/Undeploying policies to the policy framework.
+- Deploying/Undeploying microservices to the policy framework.
+- Deleting Instances.
+
+Although this GUI deploys microservices, it is a completely different paradigm to the new Automation Composition participant-based deployment of services. Details of the CLAMP GUI are provided in :ref:`clamp-policy-gui-label`
+
+2.1.2 Automation Composition GUI
+================================
+
+The current automation composition GUI is an extension of the previously created GUI for the Clamp project. The Clamp project used the CLAMP GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Although the current automation composition project builds upon this GUI, it does not rely on these connected services. Instead, the Automation Composition GUI connects to the Automation Composition Runtime only. The Automation Composition Runtime then communicates with the database and all the Automation Composition participants (indirectly) over DMAAP.
+
+The CLAMP GUI was originally housed in the clamp repository but for the Istanbul release, it has been moved to the policy/gui repo. There are 3 different GUIs within this repository - clamp-gui (and Automation Composition gui) code is housed under the "gui-clamp" directory and the majority of development takes place within the "gui-clamp/ui-react" directory.
+
+The original CLAMP GUI was created using the React framework, which is a light-weight framework that promotes use of component-based architecture. Previously, a class-based style was adopted to create the Clamp components. It was decided that Automation Composition would opt for the more concise functional style of components. This architecture style allows for the logical separation of functionality into different components and minimizes bloat. As you can see from the image, there is a "Automation Composition" directory under components where all of our Automation Composition components are housed.
+
+ .. image:: ../images/gui/ComponentFileStructure.png
+
+Any code that is directly involved in communication with outside services like Rest Apis is under "ui-react/src/api". The "fetch" Javascript library is used for these calls. The Automation Composition service communicates with just the Automation Composition Runtime Rest Api, so all of the communication code is within "ui-react/src/api/AutomationCompositionService.js".
+
+2.1.2.1 Services
+""""""""""""""""
+The Automation Composition GUI is designed to be service-centric. This means that the code involved in rendering and manipulating data is housed in a different place to the code responsible for communication with outside services. The Automation Composition related services are those responsible for making calls to the commissioning and instantiation endpoints in the Automation Composition Runtime. Another detail to note is that both the Automation Composition and CLAMP GUI use a proxy to forward requests to the policy clamp backend. Any URLs called by the frontend that contain the path "restservices/clds/v2/" are forwarded to the backend. Services are detailed below:
+
+- A commissioning call is provided for contacting the commissioning API to commission a tosca service template.
+- A decommissioning call is provided for calling the decommissioning endpoint.
+- A call to retrieve the tosca service template from the runtime is provided. This is useful for carrying out manipulations on the template, such as editing the common properties.
+- A call to get the common or instance properties is provided. This is used to provide the user an opportunity to edit these properties.
+- Calls to allow creation and deletion of an instance are provided
+- Calls to change the state of and instance are provided.
+- Calls to get the current state and ordered state of the instances, effectively monitoring.
+
+These services provide the data and communication functionality to allow the user to perform all of the actions mentioned in the :ref:`Introduction`.
+
+2.1.2.2 Components
+""""""""""""""""""
+The components in the architecture image reflect those rendered elements that are presented to the user. Each element is designed to be as user-friendly as possible, providing the user with clean uncluttered information. Note that all of these components relate to and were designed around specific system dialogues that are present in :ref:`system-level-label`.
+
+- For commissioning, the user is provided with a simple file upload. This is something the user will have seen many times before and is self explanatory.
+- For the edit of common properties, a JSON editor is used to present whatever common properties that are present in the service template to the user in as simple a way possible. The user can then edit, save and recommission.
+- A link is provided to manage the tosca service template, where the user can view the file that has been uploaded in JSON format and optionally delete it.
+- Several functions are exposed to the user in the "Manage Instances" modal. From there they can trigger, creation of an instance, view monitoring information, delete an instance and change the state.
+- Before an instance is created, the user is provided an opportunity to edit the instance properties. That is, those properties that have not been marked as common.
+- The user can change the state of the instance by using the "Change" button on the "Manage Instances" modal. This is effectively where the user can deploy and undeploy an instance.
+- Priming and De-priming take place as a result of the action of commissioning and decommissioning a tosca service template. A more complete discussion of priming and de-priming is found here :ref:`acm-participant-protocol-label`.
+- As part of the "Manage Instances" modal, we can monitor the state of the instances in 2 ways. The color of the instance highlight in the table indicates the state (grey - uninitialised, passive - yellow, green - running). Also, there is a monitoring button that allows use to view the individual elements' state.
+
+.. _Policy Clamp Backend:
+
+2.2 Policy Clamp Backend
+------------------------
+The only Rest API that the Automation Composition frontend (and CLAMP frontend) communicates with directly is the Clamp backend. The backend is written in the Springboot framework and has many functions. In this document, we will only discuss the Automation Composition related functionality. Further description of non-acm Clamp and its' architecture can be found in :ref:`architecture-label`. The backend receives the calls from the frontend and forwards the requests to other relevant APIs. In the case of the Automation Composition project, the only Rest API that it currently requires communication with is the runtime Automation Composition API. Automation Composition adopts the same "request forwarding" method as the non-acm elements in the CLAMP GUI. This forwarding is performed by Apache Camel Exchanges, which are specified in XML and can be found in the directory shown below in the Clamp repository.
+
+ .. image:: ../images/gui/CamelDirectory.png
+
+The Rest Endpoints for the GUI to call are defined in "clamp-api-v2.xml" and all of the runtime Automation Composition rest endpoints that GUI requests are forwarded to are defined in acm-flows.xml. If an Endpoint is added to the runtime Automation Composition component, or some other component you wish the GUI to communicate with, a Camel XML exchange must be defined for it here.
+
+2.3 Automation Composition Runtime
+----------------------------------
+This is where all of the endpoints for operations on Automation Compositions are defined thus far. Commissioning, decommissioning, automation composition creation, automation composition state change and automation composition deletion are all performed here. The component is written using the Springboot framework and all of the code is housed in the runtime-acm directory shown below:
+
+ .. image:: ../images/gui/RuntimeAcmDirectory.png
+
+The rest endpoints are split over two main classes; CommissioningController.java and InstantiationController.java. There are also some rest endpoints defined in the MonitoringQueryController. These classes have minimal business logic defined in them and delegate these operations to other classes within the controlloop.runtime package. The Automation Composition Runtime write all data received on its' endpoints regarding commissioning and instantiation to its; database, where it can be easily accessed later by the UI.
+
+The Runtime also communicates with the participants over DMAAP. Commissioning a automation composition definition writes it to the database but also triggers priming of the definitions over DMAAP. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over DMAAP to the participants to trigger de-priming.
+
+Using DMAAP, the Runtime can send; updates to the automation composition definitions, change the state of automation compositions, receive information about participants, receive state information about automation compositions and effectively supervise the automation compositions. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations.
+
+More detail on the design of the Runtime Automation Composition can be found in :ref:`clamp-runtime-acm`.
+
+2.4 DMAAP
+---------
+DMAAP is component that provides data movement services that transports and processes data from any source to any target. It provides the capability to:
+- Support the transfer of messages between ONAP components, as well as to other components
+- Support the transfer of data between ONAP components as well as to other components.
+- Data Filtering capabilities
+- Data Processing capabilities
+- Data routing (file based transport)
+- Message routing (event based transport)
+- Batch and event based processing
+
+Specifically, regarding the communication between the Automation Composition Runtime and the Automation Composition Participants, both components publish and subscribe to a specific topic, over which data and updates from the participants and automation compositions are sent. The Automation Composition Runtime updates the current statuses sent from the participants in the database and makes them available the the GUI over the Rest API.
+
+2.5 The Participants
+--------------------
+The purpose of the Automation Composition participants is to communicate with different services on behalf of the Automation Composition Runtime. As there are potentially many different services that a Automation Composition might require access to, there can be many different participants. For example, the kubernetes participant is responsible for carrying out operations on a kubernetes cluster with helm. As of the time of writing, there are three participants defined for the Automation Composition project; the policy participant, the kubernetes participant and the http participant. The participants are housed in the directory shown below in the policy-clamp repo.
+
+ .. image:: ../images/gui/ParticipantsDirectory.png
+
+The participants communicate with the Runtime over DMAAP. Tosca service template specifications, Automation Composition updates and state changes are shared with the participants via messages from runtime Automation Composition through the topic "POLICY-CLRUNTIME-PARTICIPANT".
+
+3. GUI Sample Flows
+###################
+The primary flows from the GUI to the backend, through DMAAP and the participants are shown in the diagram below. This diagram just serves as an illustration of the scenarios that the user will experience in the GUI. You can see factually complete dialogues in :ref:`system-level-label`.
+
+ .. image:: ../images/gui/GUI-Flow.png
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
-.. _clamp-gui-controlloop:
-
-The Policy GUI for Control Loops
-********************************
-
-.. contents::
- :depth: 4
-
-.. _Introduction:
-
-1. Introduction
-###############
-The Policy GUI for Control Loops is designed to provide a user the ability to interact with the Control Loop Runtime to perform several actions. The actual technical design of the Control Loop Runtime is detailed in :ref:`clamp-runtime-acm`. All of the endpoints and the purpose for accessing those endpoints is discussed there. In the current release of the GUI, the main purposes are to perform the below:
-
-- Commission new Tosca Service Templates.
-- Editing Common Properties.
-- Priming/De-priming Control Loop Definitions.
-- Decommission existing Tosca Service Templates.
-- Create new instances of Control Loops.
-- Change the state of the Control Loops.
-- Delete Control Loops.
-
-These functions can be carried out by accessing the Controlloop Runtime alone but this should not be required for a typical user to access the system. That is why the Controlloop GUI is required. The remainder of this document will be split into 2 main sections. The first section will show the overall architecture of ControlLoop with the GUI included, so that the reader can see where it fits in to the system. Then the section will outline the individual components required for a working GUI and outline how GUI interacts with these components and why. The final section has a diagram to show the flow of typical operations from the GUI, all the way down to the participants.
-
-2. GUI-focussed System Architecture
-###################################
-An architectural/functional diagram has bee provided in below. This does not show details of the other components involved in the GUI functionality. Most of the detail is provided for the GUI itself.
-
- .. image:: ../images/gui/GUI-Architecture.png
- :align: center
-
-The remainder of this section outlines the different elements that comprise the architecture of the GUI and how the different elements connect to one another.
-
-2.1 Policy CLAMP GUI
---------------------
-
-2.1.1 CLAMP GUI
-================
-The original Clamp project used the GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Connection to all of these services is managed by the Camel Exchange present in the section :ref:`Policy Clamp Backend`.
-
-Class-based react components are used to render the different pages related to functionality around
-
-- Creating loop instances from existing templates that have been distributed by SDC.
-- Deploying/Undeploying policies to the policy framework.
-- Deploying/Undeploying microservices to the policy framework.
-- Deleting Instances.
-
-Although this GUI deploys microservices, it is a completely different paradigm to the new ControlLoop participant-based deployment of services. Details of the CLAMP GUI are provided in :ref:`clamp-builtin-label`
-
-2.1.2 Controlloop GUI
-=====================
-
-The current control loop GUI is an extension of the previously created GUI for the Clamp project. The Clamp project used the CLAMP GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Although the current control loop project builds upon this GUI, it does not rely on these connected services. Instead, the ControlLoop GUI connects to the ControlLoop Runtime only. The ControlLoop Runtime then communicates with the database and all the ControlLoop participants (indirectly) over DMAAP.
-
-The CLAMP GUI was originally housed in the clamp repository but for the Istanbul release, it has been moved to the policy/gui repo. There are 3 different GUIs within this repository - clamp-gui (and ControlLoop gui) code is housed under the "gui-clamp" directory and the majority of development takes place within the "gui-clamp/ui-react" directory.
-
-The original CLAMP GUI was created using the React framework, which is a light-weight framework that promotes use of component-based architecture. Previously, a class-based style was adopted to create the Clamp components. It was decided that ControlLoop would opt for the more concise functional style of components. This architecture style allows for the logical separation of functionality into different components and minimizes bloat. As you can see from the image, there is a "ControlLoop" directory under components where all of our ControlLoop components are housed.
-
- .. image:: ../images/gui/ComponentFileStructure.png
-
-Any code that is directly involved in communication with outside services like Rest Apis is under "ui-react/src/api". The "fetch" Javascript library is used for these calls. The ControlLoop service communicates with just the ControlLoop Runtime Rest Api, so all of the communication code is within "ui-react/src/api/ControlLoopService.js".
-
-2.1.2.1 Services
-""""""""""""""""
-The ControlLoop GUI is designed to be service-centric. This means that the code involved in rendering and manipulating data is housed in a different place to the code responsible for communication with outside services. The ControlLoop related services are those responsible for making calls to the commissioning and instantiation endpoints in the ControlLoop Runtime. Another detail to note is that both the ControlLoop and CLAMP GUI use a proxy to forward requests to the policy clamp backend. Any URLs called by the frontend that contain the path "restservices/clds/v2/" are forwarded to the backend. Services are detailed below:
-
-- A commissioning call is provided for contacting the commissioning API to commission a tosca service template.
-- A decommissioning call is provided for calling the decommissioning endpoint.
-- A call to retrieve the tosca service template from the runtime is provided. This is useful for carrying out manipulations on the template, such as editing the common properties.
-- A call to get the common or instance properties is provided. This is used to provide the user an opportunity to edit these properties.
-- Calls to allow creation and deletion of an instance are provided
-- Calls to change the state of and instance are provided.
-- Calls to get the current state and ordered state of the instances, effectively monitoring.
-
-These services provide the data and communication functionality to allow the user to perform all of the actions mentioned in the :ref:`Introduction`.
-
-2.1.2.2 Components
-""""""""""""""""""
-The components in the architecture image reflect those rendered elements that are presented to the user. Each element is designed to be as user-friendly as possible, providing the user with clean uncluttered information. Note that all of these components relate to and were designed around specific system dialogues that are present in :ref:`system-level-label`.
-
-- For commissioning, the user is provided with a simple file upload. This is something the user will have seen many times before and is self explanatory.
-- For the edit of common properties, a JSON editor is used to present whatever common properties that are present in the service template to the user in as simple a way possible. The user can then edit, save and recommission.
-- A link is provided to manage the tosca service template, where the user can view the file that has been uploaded in JSON format and optionally delete it.
-- Several functions are exposed to the user in the "Manage Instances" modal. From there they can trigger, creation of an instance, view monitoring information, delete an instance and change the state.
-- Before an instance is created, the user is provided an opportunity to edit the instance properties. That is, those properties that have not been marked as common.
-- The user can change the state of the instance by using the "Change" button on the "Manage Instances" modal. This is effectively where the user can deploy and undeploy an instance.
-- Priming and De-priming take place as a result of the action of commissioning and decommissioning a tosca service template. A more complete discussion of priming and de-priming is found here :ref:`controlloop-participant-protocol-label`.
-- As part of the "Manage Instances" modal, we can monitor the state of the instances in 2 ways. The color of the instance highlight in the table indicates the state (grey - uninitialised, passive - yellow, green - running). Also, there is a monitoring button that allows use to view the individual elements' state.
-
-.. _Policy Clamp Backend:
-
-2.2 Policy Clamp Backend
-------------------------
-The only Rest API that the ControlLoop frontend (and CLAMP frontend) communicates with directly is the Clamp backend. The backend is written in the Springboot framework and has many functions. In this document, we will only discuss the ControlLoop related functionality. Further description of non-ControlLoop Clamp and its' architecture can be found in :ref:`clamp-builtin-label`. The backend receives the calls from the frontend and forwards the requests to other relevant APIs. In the case of the ControlLoop project, the only Rest API that it currently requires communication with is the runtime ControlLoop API. ControlLoop adopts the same "request forwarding" method as the non-ControlLoop elements in the CLAMP GUI. This forwarding is performed by Apache Camel Exchanges, which are specified in XML and can be found in the directory shown below in the Clamp repository.
-
- .. image:: ../images/gui/CamelDirectory.png
-
-The Rest Endpoints for the GUI to call are defined in "clamp-api-v2.xml" and all of the runtime ControlLoop rest endpoints that GUI requests are forwarded to are defined in ControlLoop-flows.xml. If an Endpoint is added to the runtime ControlLoop component, or some other component you wish the GUI to communicate with, a Camel XML exchange must be defined for it here.
-
-2.3 ControlLoop Runtime
------------------------
-This is where all of the endpoints for operations on ControlLoops are defined thus far. Commissioning, decommissioning, control loop creation, control loop state change and control loop deletion are all performed here. The component is written using the Springboot framework and all of the code is housed in the runtime-ControlLoop directory shown below:
-
- .. image:: ../images/gui/RuntimeControlloopDirectory.png
-
-The rest endpoints are split over two main classes; CommissioningController.java and InstantiationController.java. There are also some rest endpoints defined in the MonitoringQueryController. These classes have minimal business logic defined in them and delegate these operations to other classes within the controlloop.runtime package. The ControlLoop Runtime write all data received on its' endpoints regarding commissioning and instantiation to its; database, where it can be easily accessed later by the UI.
-
-The Runtime also communicates with the participants over DMAAP. Commissioning a control loop definition writes it to the database but also triggers priming of the definitions over DMAAP. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over DMAAP to the participants to trigger de-priming.
-
-Using DMAAP, the Runtime can send; updates to the control loop definitions, change the state of control loops, receive information about participants, receive state information about control loops and effectively supervise the control loops. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations.
-
-More detail on the design of the Runtime ControlLoop can be found in :ref:`clamp-runtime-acm`.
-
-2.4 DMAAP
----------
-DMAAP is comonent that provides data movement services that transports and processes data from any source to any target. It provides the capability to:
-- Support the transfer of messages between ONAP components, as well as to other components
-- Support the transfer of data between ONAP components as well as to other components.
-- Data Filtering capabilities
-- Data Processing capabilities
-- Data routing (file based transport)
-- Message routing (event based transport)
-- Batch and event based processing
-
-Specifically, regarding the communication between the ControlLoop Runtime and the ControlLoop Participants, both components publish and subscribe to a specific topic, over which data and updates from the participants and control loops are sent. The ControlLoop Runtime updates the current statuses sent from the participants in the database and makes them available the the GUI over the Rest API.
-
-2.5 The Participants
---------------------
-The purpose of the ControlLoop participants is to communicate with different services on behalf of the ControlLoop Runtime. As there are potentially many different services that a ControlLoop might require access to, there can be many different participants. For example, the kubernetes participant is responsible for carrying out operations on a kubernetes cluster with helm. As of the time of writing, there are three participants defined for the ControlLoop project; the policy participant, the kubernetes participant and the http participant. The participants are housed in the directory shown below in the policy-clamp repo.
-
- .. image:: ../images/gui/ParticipantsDirectory.png
-
-The participants communicate with the Runtime over DMAAP. Tosca service template specifications, ControlLoop updates and state changes are shared with the participants via messages from runtime ControlLoop through the topic "POLICY-CLRUNTIME-PARTICIPANT".
-
-3. GUI Sample Flows
-###################
-The primary flows from the GUI to the backend, through DMAAP and the participants are shown in the diagram below. This diagram just serves as an illustration of the scenarios that the user will experience in the GUI. You can see factually complete dialogues in :ref:`system-level-label`.
-
- .. image:: ../images/gui/GUI-Flow.png
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-design-impl:
+.. _clamp-acm-design-impl:
-CLAMP TOSCA Control Loop Components: Design and Implementaiton
-##############################################################
+CLAMP TOSCA Automation Composition Components: Design and Implementation
+########################################################################
-The sections below describe the components that handle TOSCA Control Loops.
+The sections below describe the components that handle TOSCA Automation Compositions.
.. toctree::
:maxdepth: 1
clamp-runtime-acm
- clamp-gui-controlloop
+ clamp-gui-acm
participants/participants
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-http-participant:
+.. _clamp-acm-http-participant:
HTTP Participant
################
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
+:ref:`Kubernetes Participant <clamp-acm-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
.. image:: ../../images/participants/http-participant.png
-The HTTP participant runs a Control Loop Element to handle the REST dialogues for a
+The HTTP participant runs a Automation Composition 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
+The HTTP participant allows the REST dialogues for a Automation Composition to be managed. A
+particular Automation Composition may require many *things* to be configured and managed and this
may require many REST dialogues to achieve.
-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
+When a automation composition is initialized, the HTTP participant starts a HTTP Automation Composition
+element for the automation composition. It reads the configuration information sent from the
+Automation Composition Runtime runs a HTTP client to talk to the REST endpoint that is receiving
+the REST requests. A HTTP participant can simultaneously manage HTTP Automation Composition
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.
+participant is running two HTTP Automation Composition Elements, one for Automation Composition A and one for
+Automation Composition B.
-Configuring a Control Loop Element on the HTTP participant for a Control Loop
------------------------------------------------------------------------------
+Configuring a Automation Composition Element on the HTTP participant for a Automation Composition
+-------------------------------------------------------------------------------------------------
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
+the Configuration Entities that it wants its HTTP Automation Composition Element to manage and
provides a sequence of parameterized REST commands to Create, Read, Update, and Delete
each Configuration Entity.
-Sample tosca template defining a http participant and a control loop element for a control loop. :download:`click here <tosca/tosca-http-participant.yml>`
+Sample tosca template defining a http participant and a automation composition element for a automation composition. :download:`click here <tosca/tosca-http-participant.yml>`
The user configures the following properties in the TOSCA for the HTTP participant:
* - configurationEntitiies
- map
- A map of *<String, ConfigurationEntity>* describing the names and definitions of
- configuration entities that are managed by this HTTP Control Loop Element
+ configuration entities that are managed by this HTTP Automation Composition Element
The *ConfigurationEntity* type is described in the following table:
Http participant Interactions:
------------------------------
-The http participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with any microservice on the southbound over http for configuration.
+The http participant interacts with Automation Composition Runtime on the northbound via DMaap. It interacts with any microservice on the southbound over http for configuration.
-The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap.
-The participant invokes the appropriate http endpoint of the microservice based on the received messages from the Control Loop Runtime.
+The communication for the Automation Composition updates and state change requests are sent from the Automation Composition Runtime to the participant via DMaap.
+The participant invokes the appropriate http endpoint of the microservice based on the received messages from the Automation Composition Runtime.
startPhase:
-----------
-The http participant is often used along with :ref:`Kubernetes Participant <clamp-controlloop-k8s-participant>` to configure the microservice after the deployment.
-This requires the Control Loop Element of http participant to be started after the completion of deployment of the microservice. This can be achieved by adding the property `startPhase`
-in the Control Loop Element of http participant. Control Loop Runtime starts the elements based on the `startPhase` value defined in the Tosca. The default value of startPhase is taken as '0'
-which takes precedence over the Control Loop Elements with the startPhase value '1'. Http Control Loop Elements are defined with value '1' in order to start the Control Loop Element in the second phase.
+The http participant is often used along with :ref:`Kubernetes Participant <clamp-acm-k8s-participant>` to configure the microservice after the deployment.
+This requires the Automation Composition Element of http participant to be started after the completion of deployment of the microservice. This can be achieved by adding the property `startPhase`
+in the Automation Composition Element of http participant. Automation Composition Runtime starts the elements based on the `startPhase` value defined in the Tosca. The default value of startPhase is taken as '0'
+which takes precedence over the Automation Composition Elements with the startPhase value '1'. Http Automation Composition Elements are defined with value '1' in order to start the Automation Composition Element in the second phase.
Http participant Workflow:
--------------------------
-Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database.
-The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap.
-Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui.
+Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Automation Composition Runtime to register this participant on the runtime database.
+The user can commission the tosca definitions from the Policy Gui to the Automation Composition Runtime that further updates the participant with these definitions via DMaap.
+Once the automation composition definitions are available in the runtime database, the Automation Composition can be instantiated with the default state "UNINITIALISED" from the Policy Gui.
-When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the http participant receives the control loop state change event from the runtime and
-configures the microservice of the corresponding Control Loop Element over http.
-The configuration entity for a microservice is associated with each Control Loop Element for the http participant.
+When the state of the Automation Composition is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the http participant receives the automation composition state change event from the runtime and
+configures the microservice of the corresponding Automation Composition Element over http.
+The configuration entity for a microservice is associated with each Automation Composition Element for the http participant.
The http participant holds the executed http requests information along with the responses received.
The participant is used in a generic way to configure any entity over http and it does not hold the information about the microservice to unconfigure/revert the configurations when the
-state of Control Loop changes from "PASSIVE" to "UNINITIALISED".
+state of Automation Composition changes from "PASSIVE" to "UNINITIALISED".
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-k8s-participant:
+.. _clamp-acm-k8s-participant:
Kubernetes Participant
######################
----------------------------------------------------------
A *chart* parameter map describes the helm chart parameters in tosca template for a microservice that is used by the kubernetes participant for the deployment.
-A Control Loop element in TOSCA is mapped to the kubernetes participant and also holds the helm chart parameters for a microservice defined under the properties of the Control Loop Element.
+A Automation Composition element in TOSCA is mapped to the kubernetes participant and also holds the helm chart parameters for a microservice defined under the properties of the Automation Composition Element.
-Sample tosca template defining a participant and a control loop element for a control loop. :download:`click here <tosca/tosca-k8s-participant.yml>`
+Sample tosca template defining a participant and a automation composition element for a automation composition. :download:`click here <tosca/tosca-k8s-participant.yml>`
-Configuring a Control Loop Element on the kubernetes participant for a Control Loop
------------------------------------------------------------------------------------
+Configuring a Automation Composition Element on the kubernetes participant for a Automation Composition
+-------------------------------------------------------------------------------------------------------
The user configures the following properties in the TOSCA template for the kubernetes participant:
Kubernetes participant Interactions:
------------------------------------
-The kubernetes participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with the helm client on the southbound for performing various helm operations to the k8s cluster.
+The kubernetes participant interacts with Automation Composition Runtime on the northbound via DMaap. It interacts with the helm client on the southbound for performing various helm operations to the k8s cluster.
-The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap.
-The participant performs appropriate operations on the k8s cluster via helm client based on the received messages from the Control Loop Runtime.
+The communication for the Automation Composition updates and state change requests are sent from the Automation Composition Runtime to the participant via DMaap.
+The participant performs appropriate operations on the k8s cluster via helm client based on the received messages from the Automation Composition Runtime.
kubernetes participant Workflow:
--------------------------------
-Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database.
-The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap.
-Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui.
+Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Automation Composition Runtime to register this participant on the runtime database.
+The user can commission the tosca definitions from the Policy Gui to the Automation Composition Runtime that further updates the participant with these definitions via DMaap.
+Once the automation composition definitions are available in the runtime database, the Automation Composition can be instantiated with the default state "UNINITIALISED" from the Policy Gui.
-When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the kubernetes participant receives the control loop state change event from the runtime and
-deploys the helm charts associated with each Control Loop Elements by creating appropriate namespace on the cluster.
+When the state of the Automation Composition is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the kubernetes participant receives the automation composition state change event from the runtime and
+deploys the helm charts associated with each Automation Composition Elements by creating appropriate namespace on the cluster.
If the repository of the helm chart is not passed via TOSCA, the participant looks for the helm chart in the configured helm repositories of helm client.
It also performs a chart look up on the local chart database where the helm charts are onboarded via the participant's REST Api.
The participant also monitors the deployed pods for the next 3 minutes until the pods comes to RUNNING state.
It holds the deployment information of the pods including the current status of the pods after the deployment.
-When the state of the Control Loop is changed from "PASSIVE" to "UNINITIALISED" back, the participant also undeploys the helm charts from the cluster that are part of the Control Loop Element.
+When the state of the Automation Composition is changed from "PASSIVE" to "UNINITIALISED" back, the participant also undeploys the helm charts from the cluster that are part of the Automation Composition Element.
REST APIs on Kubernetes participant
-----------------------------------
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-participant-intermediary:
+.. _clamp-acm-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.
+Automation Composition Element state.
Terminology
-----------
Inbound messages to participants
--------------------------------
-- PARTICIPANT_REGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantRegister message sent from a participant
-- PARTICIPANT_DEREGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantDeregister message sent from a participant
-- CONTROL_LOOP_STATE_CHANGE: a message received from controlloop runtime server for a state change of controlloop
-- CONTROL_LOOP_UPDATE: a message received from controlloop runtime server for a controlloop update with controlloop instances
-- PARTICIPANT_UPDATE: a message received from controlloop runtime server for a participant update with tosca definitions of controlloop
-- PARTICIPANT_STATUS_REQ: A status request received from controlloop runtime server to send an immediate ParticipantStatus from all participants
+- PARTICIPANT_REGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantRegister message sent from a participant
+- PARTICIPANT_DEREGISTER_ACK: received as a response from clamp-acm runtime server as an acknowledgement to ParticipantDeregister message sent from a participant
+- AUTOMATION_COMPOSITION_STATE_CHANGE: a message received from clamp-acm runtime server for a state change of clamp-acm
+- AUTOMATION_COMPOSITION_UPDATE: a message received from clamp-acm runtime server for a clamp-acm update with clamp-acm instances
+- PARTICIPANT_UPDATE: a message received from clamp-acm runtime server for a participant update with tosca definitions of clamp-acm
+- PARTICIPANT_STATUS_REQ: A status request received from clamp-acm runtime server to send an immediate ParticipantStatus from all participants
Outbound messages
-----------------
- PARTICIPANT_REGISTER: is sent by a participant during startup
- PARTICIPANT_DEREGISTER: is sent by a participant during shutdown
- PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant
-- CONTROLLOOP_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopStateChange
-- CONTROLLOOP_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopUpdate
+- AUTOMATIONCOMPOSITION_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionStateChange
+- AUTOMATIONCOMPOSITION_UPDATE_ACK: is an acknowledgement sent by a participant as a response to AutomationCompositionUpdate
- PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate
Design of a PARTICIPANT_REGISTER message
- It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered
- Participant is not monitored.
-Design of a creation of a Control Loop Type
--------------------------------------------
+Design of a creation of an Automation Composition Type
+------------------------------------------------------
- If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message
- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition)
- Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler
-Design of a deletion of a Control Loop Type
--------------------------------------------
+Design of a deletion of an Automation Composition Type
+------------------------------------------------------
- if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message
- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition
-- It deletes the Control Loop Type from DB
+- It deletes the Automation Composition Type from DB
- Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler
-Design of a creation of a Control Loop
---------------------------------------
-- CONTROL_LOOP_UPDATE message with instantiation details and UNINITIALISED state is sent to participants
+Design of a creation of an Automation Composition
+-------------------------------------------------
+- AUTOMATION_COMPOSITION_UPDATE message with instantiation details and UNINITIALISED state is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_UPDATE message and sends the details of ControlLoopElements to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_UPDATE message and sends the details of AutomationCompositionElements to participants
- Each participant performs its designated job of deployment by interacting with respective frameworks
-Design of a deletion of a Control Loop
---------------------------------------
-- CONTROL_LOOP_STATE_CHANGE message with UNINITIALISED state is sent to participants
+Design of a deletion of an Automation Composition
+-------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with UNINITIALISED state is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of ControlLoopElements to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of AutomationCompositionElements to participants
- Each participant performs its designated job of undeployment by interacting with respective frameworks
-Design of "issues control loop commands to control loops" - case UNINITIALISED to PASSIVE
------------------------------------------------------------------------------------------
-- CONTROL_LOOP_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants
+Design of "issues automation composition commands to automation compositions" - case UNINITIALISED to PASSIVE
+-------------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants
- Each participant performs its designated job of state change by interacting with respective frameworks
-Design of "issues control loop commands to control loops" - case PASSIVE to UNINITIALISED
------------------------------------------------------------------------------------------
-- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants
+Design of "issues automation composition commands to automation compositions" - case PASSIVE to UNINITIALISED
+-------------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants
- Each participant performs its designated job of state change by interacting with respective frameworks
-Design of "issues control loop commands to control loops" - case PASSIVE to RUNNING
------------------------------------------------------------------------------------
-- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants
+Design of "issues automation composition commands to automation compositions" - case PASSIVE to RUNNING
+-------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants
- Each participant performs its designated job of state change by interacting with respective frameworks
-Design of "issues control loop commands to control loops" - case RUNNING to PASSIVE
------------------------------------------------------------------------------------
-- CONTROL_LOOP_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants
+Design of "issues automation composition commands to automation compositions" - case RUNNING to PASSIVE
+-------------------------------------------------------------------------------------------------------
+- AUTOMATION_COMPOSITION_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants
- Participant-intermediary validates the current state change
-- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants
+- Participant-intermediary will recieve AUTOMATION_COMPOSITION_STATE_CHANGE message and sends the details of state change to participants
- Each participant performs its designated job of state change by interacting with respective frameworks
Design of a PARTICIPANT_STATUS message
- This message will hold the state and healthStatus of all the participants running actively
- PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ
-Design of a CONTROLLOOP_UPDATE_ACK message
-------------------------------------------
-- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message.
-- For each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE
-- ControlLoopUpdateAckListener in CL-runtime collects the messages from DMaap
-- It checks the status of all control loop elements and checks if the control loop is primed
-- It updates the controlloop in DB accordingly
+Design of a AUTOMATIONCOMPOSITION_UPDATE_ACK message
+----------------------------------------------------
+- A participant sends AUTOMATIONCOMPOSITION_UPDATE_ACK message in response to a AUTOMATIONCOMPOSITION_UPDATE message.
+- For each CL-elements moved to the ordered state as indicated by the AUTOMATIONCOMPOSITION_UPDATE
+- AutomationCompositionUpdateAckListener in CL-runtime collects the messages from DMaap
+- It checks the status of all automation composition elements and checks if the automation composition is primed
+- It updates the clamp-acm in DB accordingly
-Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK
+Design of a AUTOMATIONCOMPOSITION_STATECHANGE_ACK is similar to the design for AUTOMATIONCOMPOSITION_UPDATE_ACK
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-participant-simulator:
+.. _clamp-acm-participant-simulator:
Participant Simulator
#####################
This can be used for simulation testing purpose when there are no actual frameworks or a full deployment.
-Participant simulator can edit the states of ControlLoopElements and Participants for verification of other controlloop components
+Participant simulator can edit the states of AutomationCompositionElements and Participants for verification of other clamp-acm components
for early testing.
-All controlloop components should be setup, except participant frameworks (for example, no policy framework components
+All clamp-acm components should be setup, except participant frameworks (for example, no policy framework components
are needed) and participant simulator acts as respective participant framework, and state changes can be done with following REST APIs
Participant Simulator API
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-participants:
+.. _clamp-acm-participants:
-Control Loop Participants
-#########################
+Automation Composition 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
+A Participant is a component that acts as a bridge between the CLAMP Automation Composition Management runtime and components such as
+the Policy Framework, DCAE, or a Kubernetes cluster that are taking part in automation composition management. 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
+are taking part in acms. A participant has an Automation Composition Management Element for each automation composition 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
+:ref:`Participant Intermediary library <clamp-acm-participant-intermediary>`, which carries out common
+message and state handling for Automation Composition 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.
+wishes to take part in automation composition management.
.. image:: ../../images/participants/participants.png
-The figure above shows participants for various components that may take part in control loops.
+The figure above shows participants for various components that may take part in automation composition management.
.. 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
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. _clamp-controlloop-policy-framework-participant:
+.. _clamp-acm-policy-framework-participant:
The CLAMP Policy Framework Participant
######################################
.. contents::
:depth: 3
-Control Loop Elements in the Policy Framework Participant are configured using TOSCA metadata defined for the Policy Control Loop Element type.
+Automation Composition Elements in the Policy Framework Participant are configured using TOSCA metadata defined for the Policy Automation Composition Element type.
The Policy Framework participant receives messages through participant-intermediary common code, and handles them by invoking REST APIs towards policy-framework.
-For example, When a ControlLoopUpdate message is received by policy participant, it contains full ToscaServiceTemplate describing all components participating in a control loop. When the control loop element state changed from UNINITIALIZED to PASSIVE, the Policy-participant triggers the creation of policy-types and policies in Policy-Framework.
+For example, When a AutomationCompositionUpdate message is received by policy participant, it contains full ToscaServiceTemplate describing all components participating in an automation composition. When the automation composition element state changed from UNINITIALIZED to PASSIVE, the Policy-participant triggers the creation of policy-types and policies in Policy-Framework.
When the state changes from PASSIVE to UNINITIALIZED, Policy-Participant deletes the policies, policy-types by invoking REST APIs towards the policy-framework.
The Policy Framework participant uses the Policy PAP API to deploy and undeploy policies.
-When a Policy Framework Control Loop Element changes from state PASSIVE to state RUNNING, the policy is deployed. When it changes from state RUNNING to state PASSIVE, the policy is undeployed.
+When a Policy Framework Automation Composition Element changes from state UNINITIALISED to state PASSIVE, the policy is deployed. When it changes from state PASSIVE to state UNINITIALISED, the policy is undeployed.
-The PDP group to which the policy should be deployed is specified in the Control Loop Element metadata, see the Policy Control Loop Element type definition. If the PDP group specified for policy deployment does not exist, an error is reported.
+The PDP group to which the policy should be deployed is specified in the Automation Composition Element metadata, see the Policy Automation Composition Element type definition. If the PDP group specified for policy deployment does not exist, an error is reported.
The PAP Policy Status API and Policy Deployment Status API are used to retrieve data to report on the deployment status of policies in Participant Status messages.
Policy Type and Policy References
+++++++++++++++++++++++++++++++++
-The Policy Framework uses the policyType and policyId properties defined in the Policy Control Loop Element type references to specify what policy type and policy should be used by a Policy Control Loop Element.
+The Policy Framework uses the policyType and policyId properties defined in the Policy Automation Composition Element type references to specify what policy type and policy should be used by a Policy Automation Composition Element.
-The Policy Type and Policy specified in the policyType and policyId reference must of course be available in the Policy Framework in order for them to be used in Control Loop instances. In some cases, the Policy Type and/or the Policy may be already loaded in the Policy Framework. In other cases, the Policy Framework participant must load the Policy Type and/or policy.
+The Policy Type and Policy specified in the policyType and policyId reference must of course be available in the Policy Framework in order for them to be used in Automation Composition instances. In some cases, the Policy Type and/or the Policy may be already loaded in the Policy Framework. In other cases, the Policy Framework participant must load the Policy Type and/or policy.
Policy Type References
**********************
The Policy Participant uses the following steps for Policy Type References:
-#. The Policy Participant reads the Policy Type ID from the policyType property specified for the Control Loop Element.
+#. The Policy Participant reads the Policy Type ID from the policyType property specified for the Automation Composition Element.
#. It checks if a Policy Type with that Policy Type ID has been specified in the ToscaServiceTemplateFragment field in
- the ControLoopElement definition in the ControlLoopUpdate message, see :ref:`controlloop-participant-protocol-label`.
+ the AutomationCompositionElement definition in the AutomationCompositionUpdate message, see :ref:`acm-participant-protocol-label`.
#. If the Policy Type has been specified, the Participant stores the Policy Type in the Policy framework. If the
Policy Type is successfully stored, execution proceeds, otherwise an error is reported.
The Policy Participant uses the following steps for Policy References:
-#. The Policy Participant reads the Policy ID from the policyId property specified for the Control Loop Element.
+#. The Policy Participant reads the Policy ID from the policyId property specified for the Automation Composition Element.
#. It checks if a Policy with that Policy ID has been specified in the ToscaServiceTemplateFragment field in the
- ControLoopElement definition in the ControlLoopUpdate message, :ref:`controlloop-participant-protocol-label`.
+ AutomationCompositionElement definition in the AutomationCompositionUpdate message, :ref:`acm-participant-protocol-label`.
#. If the Policy has been specified, the Participant stores the Policy in the Policy framework. If the Policy is
successfully stored, execution proceeds, otherwise an error is reported.
"/onap/participantsim/v2/elements": {
"put": {
"tags": [
- "Clamp Control Loop Participant Simulator API"
+ "Clamp Automation Composition Participant Simulator API"
],
- "summary": "Updates simulated control loop elements",
- "description": "Updates simulated control loop elements, returning the updated control loop definition IDs",
+ "summary": "Updates simulated automation composition elements",
+ "description": "Updates simulated automation composition elements, returning the updated automation composition definition IDs",
"operationId": "updateUsingPUT",
"consumes": [
"application/json"
{
"in": "body",
"name": "body",
- "description": "Body of a control loop element",
+ "description": "Body of a automation composition element",
"required": true,
"schema": {
- "$ref": "#/definitions/ControlLoopElementReq",
- "originalRef": "ControlLoopElementReq"
+ "$ref": "#/definitions/AutomationCompositionElementReq",
+ "originalRef": "AutomationCompositionElementReq"
}
},
{
"200": {
"description": "OK",
"schema": {
- "$ref": "#/definitions/TypedSimpleResponse«ControlLoopElement»",
- "originalRef": "TypedSimpleResponse«ControlLoopElement»"
+ "$ref": "#/definitions/TypedSimpleResponse«AutomationCompositionElement»",
+ "originalRef": "TypedSimpleResponse«AutomationCompositionElement»"
}
},
"201": {
"/onap/participantsim/v2/elements/{name}/{version}": {
"get": {
"tags": [
- "Clamp Control Loop Participant Simulator API"
+ "Clamp Automation Composition Participant Simulator API"
],
- "summary": "Query details of the requested simulated control loop elements",
- "description": "Queries details of the requested simulated control loop elements, returning all control loop element details",
+ "summary": "Query details of the requested simulated automation composition elements",
+ "description": "Queries details of the requested simulated automation composition elements, returning all automation composition element details",
"operationId": "elementsUsingGET",
"produces": [
"application/json",
{
"name": "name",
"in": "path",
- "description": "Control loop element name",
+ "description": "Automation Composition element name",
"required": true,
"type": "string"
},
{
"name": "version",
"in": "path",
- "description": "Control loop element version",
+ "description": "Automation Composition element version",
"required": true,
"type": "string"
},
"schema": {
"type": "object",
"additionalProperties": {
- "$ref": "#/definitions/ControlLoopElementRes",
- "originalRef": "ControlLoopElementRes"
+ "$ref": "#/definitions/AutomationCompositionElementRes",
+ "originalRef": "AutomationCompositionElementRes"
}
}
},
"/onap/participantsim/v2/participants": {
"put": {
"tags": [
- "Clamp Control Loop Participant Simulator API"
+ "Clamp Automation Composition Participant Simulator API"
],
"summary": "Updates simulated participants",
- "description": "Updates simulated participants, returning the updated control loop definition IDs",
+ "description": "Updates simulated participants, returning the updated automation composition definition IDs",
"operationId": "updateUsingPUT_1",
"consumes": [
"application/json"
"/onap/participantsim/v2/participants/{name}/{version}": {
"get": {
"tags": [
- "Clamp Control Loop Participant Simulator API"
+ "Clamp Automation Composition Participant Simulator API"
],
"summary": "Query details of the requested simulated participants",
"description": "Queries details of the requested simulated participants, returning all participant details",
version:
type: string
required: true
- onap.datatype.controlloop.Target:
+ onap.datatype.acm.Target:
derived_from: tosca.datatypes.Root
- description: Definition for a entity in A&AI to perform a control loop operation on
+ description: Definition for a entity in A&AI to perform a automation composition operation on
properties:
targetType:
type: string
clamp_possible_values: ClampExecution:CSAR_RESOURCES
entry_schema:
type: string
- onap.datatype.controlloop.Actor:
+ onap.datatype.acm.Actor:
derived_from: tosca.datatypes.Root
description: An actor/operation/target definition
properties:
clamp_possible_values: Dictionary:DefaultOperations,ClampExecution:CDS/operation
required: true
target:
- type: onap.datatype.controlloop.Target
+ type: onap.datatype.acm.Target
description: The resource the operation should be performed on.
required: true
payload:
clamp_possible_values: ClampExecution:CDS/payload
entry_schema:
type: string
- onap.datatype.controlloop.Operation:
+ onap.datatype.acm.Operation:
derived_from: tosca.datatypes.Root
description: An operation supported by an actor
properties:
description: A user-friendly description of the intent for the operation
required: false
operation:
- type: onap.datatype.controlloop.Actor
+ type: onap.datatype.acm.Actor
description: The definition of the operation to be performed.
required: true
timeout:
required: false
default: final_failure_guard
node_types:
- org.onap.policy.clamp.controlloop.Participant:
+ org.onap.policy.clamp.acm.Participant:
version: 1.0.1
derived_from: tosca.nodetypes.Root
properties:
provider:
type: string
requred: false
- org.onap.policy.clamp.controlloop.ControlLoopElement:
+ org.onap.policy.clamp.acm.AutomationCompositionElement:
version: 1.0.1
derived_from: tosca.nodetypes.Root
properties:
required: false
metadata:
common: true
- description: Specifies the organization that provides the control loop element
+ description: Specifies the organization that provides the automation composition element
participant_id:
type: onap.datatypes.ToscaConceptIdentifier
requred: true
required: true
metadata:
common: true
- description: The identity of the participant type that hosts this type of Control Loop Element
+ description: The identity of the participant type that hosts this type of automation composition Element
startPhase:
type: integer
required: false
- greater_or_equal: 0
metadata:
common: true
- description: A value indicating the start phase in which this control loop element will be started, the
- first start phase is zero. Control Loop Elements are started in their start_phase order and stopped
- in reverse start phase order. Control Loop Elements with the same start phase are started and
+ description: A value indicating the start phase in which this automation composition element will be started, the
+ first start phase is zero. Automation Composition Elements are started in their start_phase order and stopped
+ in reverse start phase order. Automation Composition Elements with the same start phase are started and
stopped simultaneously
uninitializedToPassiveTimeout:
type: integer
metadata:
common: true
description: The maximum time in seconds to wait for a state chage from passive to uninitialized
- org.onap.policy.clamp.controlloop.ControlLoop:
+ org.onap.policy.clamp.acm.AutomationComposition:
version: 1.0.1
derived_from: tosca.nodetypes.Root
properties:
required: false
metadata:
common: true
- description: Specifies the organization that provides the control loop element
+ description: Specifies the organization that provides the automation composition element
elements:
type: list
required: true
common: true
entry_schema:
type: onap.datatypes.ToscaConceptIdentifier
- description: Specifies a list of control loop element definitions that make up this control loop definition
- org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement:
+ description: Specifies a list of automation composition element definitions that make up this automation composition definition
+ org.onap.policy.clamp.acm.K8SMicroserviceAutomationCompositionElement:
version: 1.0.1
- derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement
+ derived_from: org.onap.policy.clamp.acm.AutomationCompositionElement
properties:
chart:
type: string
topology_template:
node_templates:
- org.onap.k8s.controlloop.K8SControlLoopParticipant:
+ org.onap.k8s.acm.K8SAutomationCompositionParticipant:
version: 2.3.4
- type: org.onap.policy.clamp.controlloop.Participant
+ type: org.onap.policy.clamp.acm.Participant
type_version: 1.0.1
description: Participant for K8S
properties:
provider: ONAP
- org.onap.domain.database.PMSH_K8SMicroserviceControlLoopElement:
+ org.onap.domain.database.PMSH_K8SMicroserviceAutomationCompositionElement:
# Chart from new repository
version: 1.2.3
- type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement
+ type: org.onap.policy.clamp.acm.K8SMicroserviceAutomationCompositionElement
type_version: 1.0.0
- description: Control loop element for the K8S microservice for PMSH
+ description: Automation composition element for the K8S microservice for PMSH
properties:
provider: ONAP
participant_id:
name: K8sParticipant0
version: 1.0.0
participantType:
- name: org.onap.k8s.controlloop.K8SControlLoopParticipant
+ name: org.onap.k8s.acm.K8SAutomationCompositionParticipant
version: 2.3.4
chart:
chartId:
overrideParams:
global.masterPassword: test
- org.onap.domain.database.Local_K8SMicroserviceControlLoopElement:
+ org.onap.domain.database.Local_K8SMicroserviceAutomationCompositionElement:
# Chart installation without passing repository info
version: 1.2.3
- type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement
+ type: org.onap.policy.clamp.acm.K8SMicroserviceAutomationCompositionElement
type_version: 1.0.0
- description: Control loop element for the K8S microservice for local chart
+ description: Automation composition element for the K8S microservice for local chart
properties:
provider: ONAP
participant_id:
name: K8sParticipant0
version: 1.0.0
participantType:
- name: org.onap.k8s.controlloop.K8SControlLoopParticipant
+ name: org.onap.k8s.acm.K8SAutomationCompositionParticipant
version: 2.3.4
chart:
chartId:
version: 0.9.1
releaseName: nginxms
namespace: test
- org.onap.domain.sample.GenericK8s_ControlLoopDefinition:
+ org.onap.domain.sample.GenericK8s_AutomationCompositionDefinition:
version: 1.2.3
- type: org.onap.policy.clamp.controlloop.ControlLoop
+ type: org.onap.policy.clamp.acm.AutomationComposition
type_version: 1.0.0
- description: Control loop for Hello World
+ description: Automation composition for Hello World
properties:
provider: ONAP
elements:
- - name: org.onap.domain.database.PMSH_K8SMicroserviceControlLoopElement
+ - name: org.onap.domain.database.PMSH_K8SMicroserviceAutomationCompositionElement
version: 1.2.3
- - name: org.onap.domain.database.Local_K8SMicroserviceControlLoopElement
+ - name: org.onap.domain.database.Local_K8SMicroserviceAutomationCompositionElement
version: 1.2.3
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T12:49:40.502Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="93W7hVhu2wOsYupjcs14" version="17.4.0" type="device"><diagram id="RYPNdAOSzT_k6u516NDZ" name="Page-1">7Zxbd5s4EIB/jR/jAxI3P+banm13N7tJN+3THmJkmwaQCzix8+srgQRIwi4mgJvEfvBBQgjQfJoZaSRG8Dxcf4jd5eJP7KFgBDRvPYIXIwAMRyP/NGOTZ+i2nWfMY99jWWXGjf+MWCa7br7yPZQIBVOMg9RfiplTHEVomgp5bhzjJ7HYDAfiXZfuHCkZN1M3UHPvfC9d5LkOsMv8j8ifL/iddWuSnwldXpi9SbJwPfxUyYKXI3geY5zmR+H6HAW07Xi75NddbTlbPFiMorTJBV9v9ZXxw/hi3f1/d/b97Mv9h2frBIK8mkc3WLE3vv375vyUZJ2uUkxewscRSZzjcIkTP09ZAbnh2X1Mjub06ALN/Iidy9403fDmIy+9pIerMLiK3ZAcnj0t/BTdLN0pzX8i0JC8RRoGJKWTwxivIg/RZ9ZIqmg0mpji0J+y48C9R8GZO32YZxec4wDH5FSEI3qPJI3xQyEwWu0MR+mVG/oB5fA/FHtu5LJsBp1Oq3UDfx6RxJQ0Korp0/I6bHp6wUUNaWrmB4F0Y1UoTE6PKE7RupLFhPQB4RCl8YYU4WdNBgzvMSz5VOJnGixvUUHP5AVdhvy8qLqkghwwMPaBBCqQKIJGkXdKuxttu8BNEiqoqlhJe8Sbr9XENybJLHGxFlIbnlr7Kb1IG5ss9Y1XQY7Li2iCX7NVBAlexVO04z1N1qlTN56jdEdBi9WIPEF5qCKtyqxOZCwvRgHpaI+iyqkTI7vDNfbJuxXEmJYtEAM1iYT8zdlVVRUhV6TpQkUmhKThharytlGqyrgqXvwFqNl7oYaXKJI540ZEB5kicOOUl/Z8N8SRd7vwI36KlzV4xpUfFFUR6d6w2+I4XeA5jtzgsswttEWAZlQP0j7uE9NxyrLvcUpUaBV+xvH++IMh+Dea8m825Z9xdSJiBTuhHjpAqNVw2kGvS/VAKPWevpF39kL+PsDTByJmz00WmZlk1DNwNbUP1GlhbWwLJOqNSaTNXqJ4oo01zdrJI01co9gn7UQt6m5G99GoutWN+oTAHuu2JRpdh76YPil+LeGCwBpLfOmGRm6nlT9jWNwmA+JW6i/NqVBD2jbTuB1B82vDrh2OrhOul7h6sVqiBAyFo0bgEEm6m0qxJS2Q9IEWf6BDG2+tkfFu41u2NeQvQBc0tcl2Q8ZfyHMxgOc8222dTVOsCMgVHZ5nXeE5VICOUeI/u/dZUhNx/oV7mOLl9oHsCMBZ9qsZpKo07eyObGqEPeOomJBoPiTl/ttLxyniBXg2S1AvNo5ryorg9PFYnZ1oILs4H629YuF1IzsuPNZZT4A2mDD3m304tH9sTeyqp/O6XWNzoo81S3GNWyr8iTgMbOrAdAaSMSBI9SP33Ti8wEtoavx7YEQZP7d1cA27awe32X0AFCbOyUFeY7fwmXvB91omtgrM7d9qgoqPuQ46QWXoImdmy35hSwM/a2C1aSnkfiS3BtrtZol2MbxPHKAcTv3KwArTCGZfoDkNQWs8EzpMJMCSUIFmS1ttTaSK5JBC39CpcQAWl5R4S578MHCz2FuFsszpZoWyyOHCD7zP7gavaHsTfTh94KmzBY79Z1Le5RcL+lPfEugrr7qhtbH7ZAMKdM2J04usz26S8mfBQeAuEz/36GmRkLSlH50xpZrHPdlrXVXuXB1V/GZR0q09rfkwRZ7OB2rY06npOMDZ3kdeFPQ01Gl5Hhn/C3uI6j8ULl3SXVUl2DOU24LPRyY7ZtIE0oilJhav18Xi5RBSd1Sqs/fb12nUW+ijxnwjdAJLGi85NXRyp3MQnWmqAYAddF4GKESZ03EITo9KdChMuevIDXsNpkADAypRU53Xl037Ecg3DCSU9GadVQdDWnUe5GumN7PllvWrLY+m/W0gamoNTLs9qGlXozAfb2+vR7vWCZcW/qhJ3ySmUMLU0OpMew2m/WnSdjGeyuS6NZKjPPXxQdAuPjgaYvqSd9aDrKaTmIC2FPZvvN7JmYzFoDOUV7h3FBACE9FDNfQBAkLmfgGhN0pqm5X0fZFqmK+PVGcIUtUA0Hsk9YBrSBVSJ6a8L+MVsGoOwaoaN2o0A8W2sA0/pjr6qgP5qoYp9qFiuWnVVwWD+qr7bfzoJ5z+e22sa+O49rmxTl7rLKvKxkubpKl66Ay7rc7cb9PHe0CtjT1/DaiZ8qojTfEVeoaNt2wFtmsc+NPNcbLoPRtgqEHRHzTqJovsAQ2wpcaBPq3uURyhFCVHWN83rNKIy9FVWGHdBLzZF6xAgTVfhplmsUoNz+hfxA8lLslrpyKTeXNLMpiJAr7KfnVNLK8IDn3Py1YO133dQ8SjC19eWsFdbNmujr31GmMt71ppI51HtH6++OePTw/h3b8zcB5epd9PT1RNssu/Uld3l00kTYlYhl11t+h+azadssPjoil5X0nphhmQb9jOHLGxBiY7nbG6XSpb90EU6833WaxeqarWKWu5iHfS0BU0tXrahvH8oDRPAtqu2S0MarGCsrc1u7V9QFVQ/FNBVGMLncH6scL8xEmSkUJXX+jacl2e5J8XCnk15KnymvL8LpQcy+pevynKrIbh7dYHiluu6r4BVKfeuvgCUK1o67bgdSHafFfme5OuJk7AAsvsS7okWX5gLO/n5Vfa4OVP</diagram></mxfile>
\ No newline at end of file
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T09:12:37.309Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" version="17.4.0" etag="fA0oINVl5eVVmPUGOO6X" type="device"><diagram id="cbTz21U9R7ytQ8vLfwRy" name="Page-1">7Vvdc+I2EP9rmGkfksEyxvAYIGlvJm2vk0zbe7oRWGD1ZMu1RQL313dlS/6QTCAc5tKUewjWSlpLu7/90MrXc6fR5qcUJ+EvPCCsh/rBpufOegih/hDBj6RsC4qvCauUBgXJqQgP9CtRxL6irmlAssZAwTkTNGkSFzyOyUI0aDhN+XNz2JKz5lsTvCIW4WGBmU39kwYiLKgj5Ff0nwldhfrNznBc9ERYD1Y7yUIc8Ocayb3tudOUc1E8RZspYVJ4Wi7FvLsdveXCUhKLQyYEvz9tJvd/f/acafiBjaPsYzS5Usp4wmytNtxDQwb8JlmCY7lqsVWiGP6zlkudLHksrpY4ogxUetOTbx3iKIGeHnLdAfw+kTTAMbbocmz+N2eR5bqWDJx+sin75njxZZXydRxcLTjjaTEkXc1/QJ6Xv20Kf43nH6vlwdNK/j7+9jCVM2/WgoMuKJe7mfIo4RktWmp18TwrFlnsGwRYbL1g817EcQcccARQwSyXQ7wgich2bho19ooAu4l8XEfsLgU2MOY5pII8JHgh6c9g/EALRcSg5UixUMamxYJnMY/zGcp+UL63UFuN2y/fCJISZLMT305pNeBuCI+ISLcwRE8YqinK0wyU3T1XZjsYK1pYM1l3qIhYuYpVybqyJnhQBvUK43Jcy7o0Kn8FRwk/j1sQqyXsZxoxnIusLlAAyYMaJCW2CCkL7vGWr+U+MgE40a1JyFP6lee6LiZDdyqUc3Wcfrt+qlkPkpt6T0okMj9qNTgl6R5nQq+FM4aTjM7z1ckhEU5XNJ5wAcanBult3dXeDKawzP9JrhLkJNCjtbcs+Ed0oZ4ZnhM2Ka3C2EMmUv6l9NRabnfKPGd/KFNU4lQCkWwxo6sYGgvYJklPg0h30ESkM7Qh6aA2SHaGyIGFyN3+8YLOd43OgddEZ4m6OjqH50Sn35KMGOgjcXAjszpozRmXMJgEOAtzxUh5Qr/UoNIGtLQUUROvIKN0+5ccdu17uv2p3jnblExka6tbGyqKechTzU+1rmqWbOhJxTZIYKWahq5gq3ydLsgBFgwmsyJib/Cxtd+m3ZQw8ABPzdW1qVex+8gprLtEEqQsDSR5nttkUexKzaqnqAYjx2DkeuMmo2LXFqMcbeUev8E9eq9xj7eMyITqOzlK9+Inz+QnjSjutvhJ1G/xk93llUMLpjkyPichzmwgwtZFE4SFfA2ht2BJi5ORpSgOMoLC0fhGkQVPdhwEDBRAJ41X9zmXGTpULS+YqK0srZwDddNZDBudMYYdE4pqge9Vce+UIcx7eyFsZJwdHf+4COYfF8AAD3hbG5bIAdnu5Q5cI3cbNmo/8FBwPG10tPMzfZydYYEvB4Z3Hgid0Zs7ztreViNSVbjg6UMA+6NLCmI4MzTRBZlnQqZ/wFF2cNYUbdySBxS11oA+6TprLEupVQm21tMyGCSUFXXrvGeemmNNDm87DfS+LQ0cvZgGogP1P+hK/23q7zwN/G9lgaNDs0D/bFmgP2y4Ec8xsreD6xhGeuaMjILIq9PAU1c6tIHUAAqRB8ya4uS7lTQuqdy5AmY5pTyntDjMs56bHWQBMl3HgP2+DHkGDmvgM4PRXCl20uJeS09Z95PV4XmPq3TqjrLmN9/Qgbn2XUGb1q/6185o7DY0P7L0PjqRL91zEj7Yl3rHHakrRnogXy4z0k3d2LmE+z0Y1gFnf7jfkdl1cW9h3oD5R95bmIycsVE++v7x3kaoOilfQvz7DPGuEeJHdoQfnTPA23cWL7lInpDY8HtNj5iDSo8OKI54HDyGNDbxNtAE5VxzVuDQNJp5KkK+4jFmtxV134m3lmS0O9bKle67RfbrXlz7985vkctPKY8tweuMwojNJ3HLVsT3j0wdXGcPo66vk+1D1gXz5nXVG8T8joJDl5h3UbP04KAjL6DGRibiG0s50QWU9WnboP/istDL47u5sEL295evs79mVtDM0PcZ4+5k3rLVQ0H+YlLstQRz7zR5sud6DeVZZfNDwWkycs1so2OHjOzPHx9lVdwExbeXystMznSjEQ2C3N3ur5efIgk0PqhCLXWes37ih+wvrJzra7vCY2vgcMnmJwQ8Lw8rypcBX2/S82aS11rwTBngK5Rrpu0nUJCnbyC0glrSdLdFQagzBdl5evQ/1o7hrxxbO20X3kdoB5rVfwUq/F31H6rc238B</diagram></mxfile>
\ No newline at end of file
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2022-04-05T09:14:50.017Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36" etag="N8ksXkiLfCb-aaYhfdFz" version="17.4.0" type="device"><diagram id="2XpnY2_hXlSYiaPWDiV9" name="Page-1">7ZpRc+MmEIB/jR/PI5Al24+JE186TaeZsdtL+9LBFrZokNAhfLbv1xckkCUhO0pqpWnOeQksCwj2Y2HBPXcS7T5zlIS/sADTHnSCXc+96UEIHR/Kf0qyzyVDI1hzEuQicBDMyHeshY6WbkiA04qiYIwKklSFSxbHeCkqMsQ521bVVoxWe03QGluC2RJRW/qFBCLMpSM4PMjvMFmHpmfgj/OSCBllPZI0RAHblkTubc+dcMZEnop2E0zV5Jl5yetNj5QWH8ZxLNpUcPzt18fJzQI4f352pn/z+Z6IT7qVb4hu9IDnv84mV1I0EygOEA9k8mojmBwOYbHMTFiUsJTo3C3Fkew/1UMUezNvcrSJSm4iOuUoksnrbUgEniVoqeRbiYuUhSKiMgdkkrNNHGD1sY7MFbOlMksWkaVOU7TA9Botn9ZZhQmjjMuimMWqj1Rw9lRYSjW7YrGYoohQBeDvmAcoRlqsaQOqWUTJOpaZpRwN5uprTRu+Kg6NjV2VWxFKax3recRc4N1RA4HC7HK9YBZhwfdSxVTQTO3N2smz2wN2w7GWhSXkBo4WIo36umj5QINMaCBeAAe04OCbWJraUaav2btkSDUJRK6gKz2lCyYkP7IAx8GVWpJKRtnySYl2RDxqy6r0Hyrdh57O3uxKZTd7k4nl6B51b1kmr+aZ7KFaljP18o/GgbXiaxaSA2MbvsQnpsbXrgjxNRYn9EYnLe70pbuAVatbRh9p83JM5Rr8Vv32Jpvr7h4YkaMq+voEXE/OULkvAL1qK/mwdcWyK6m35T3bVD4zJ5oyimy1SnFFJ2O1mKzX4+ta+FrUNhEZm10I+Hl2SlS/GUElygsInZdBWBDf98rMnwT+jOCOW4I7bAa3xKVyjOcAE4JBDSY4eiWX7vDZpo5weS7mBm/EnHaRBjvwvqED4N1RB8bjOirua6lzqi4c+O2YkxSgfUktUQrp8U92/doBYeDVEM5bPCvQ3lsBPfxfAe2+O6D9YR3owfi1QI/qbrQt0ueizreoez4Gkan5XsYcViSyJRFF2SG9RF52/tdKWYgREhrcoz3bKHOmQgYYJncdMk6+S31kKstibqKHYwHBodJMNaa74TiV1R4McqAQ3aNUmE9hlKIkJYvs45RKJGebxNf6HJ3HR3pU01LPPeiusr/3F031/n14BL06lYbv0mqCDjRK5RjJ7ypEGlqgZmz8lYQotVGUgxdVDPMZrk17A01mQileiYYQS7DkSIBd40AWknh9n7VyA9sa5vgata21N5tiW9u4XdlmZNlGrjs5bQQl/5m3AODiLt7GXdh7GLDdBXAaLlTgqCMgxzaQjJLlvtUV22Vf+6CgQk+dfSsHe79hY4OgD99yZzMX8CVak4zWn4KPva+NX7yvHTFNZxsbsG/tf94sMI+xwOnFmfzQzmRYvSNwnQZXMmzY9ADojFb7GaEHfaqYCcg3mVyLDC1Ji5HLfkpFTdosXpF12lqf468bws1TVctKAkeJDMlx+xrZEAv1Ba+r1hv4yG4UHAH1hB9t4nLUGZb288DdfP5wcZ8/svv0Rn71JOY2uE/QgOm4M0ybXhQsx7NAKf6N09aOKhQiucMowLy9c8t97oZnK+M2FnJNXHxd2Ze8yNc1QdTdWd6+xT/h5C73Ih/ZxUHfeiNtuBcZNl7VdXYzAuwLf4vA0jMTS3DcO/LjoYIsoxwQFLE4mIckNkWlx6jq01Tp3QrWCR302j8hnXzx8RqWvneeRyDX8/r+0Cn+QMXQnlttr/V7kFfdFevvSh0/BgH7kj3qYD8pFll9R4lIEKhuWmwqZ1if9VdeY7TKrWVD/NbZ3mFfo4N+3/4B2McxgAlDtAFGoCsDyOzh55/5ajn8iNa9/Qc=</diagram></mxfile>
\ No newline at end of file
CLAMP Metadata Automation Composition Management using TOSCA
#############################################################
-CLAMP supports the definition, deployment, and life cycle management of automation compostion elements using Metadata
+CLAMP supports the definition, deployment, and life cycle management of automation composition elements using Metadata
described in TOSCA.
.. toctree::
:maxdepth: 2
- acm/controlloop-architecture
- acm/defining-controlloops
- acm/api-protocol/api-protocol
+ acm/acm-architecture
+ acm/defining-acms
+ acm/api-protocol/api-protocol-tree
+ acm/clamp-gui/policy-gui
acm/design-impl/design-impl
.. note::
POST: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/commission
-A successful commissioning gives 200 response in the postman client.
+A successful commissioning gives 200 responses in the postman client.
3.2 Create New Instances of Automation composition
3.3 Change the State of the Instance
====================================
-When the automation composition is updated with state “PASSIVE”, the Kubernetes participant fetches the node template for all automation composition elements and deploys the helm chart of each AC element in to the cluster. The following sample json input is passed on the request body.
+When the automation composition is updated with state “PASSIVE”, the Kubernetes participant fetches the node template for all automation composition elements and deploys the helm chart of each AC element into the cluster. The following sample json input is passed on the request body.
Automation Composition Update Endpoint:
testsuites/performance/performance-benchmark-test/src/main/resources/apexPdpPerformanceTestPlan.jmx
.. Note::
- Policy executions are validated in a more strict fashion during the tests.
- There are test cases where upto 80 events are expected on the DMaaP topic.
+ Policy executions are validated in a stricter fashion during the tests.
+ There are test cases where up to 80 events are expected on the DMaaP topic.
DMaaP simulator is used to keep it simple and avoid any message pickup timing related issues.
Stability Test of APEX-PDP
- **HTTP Authorization Manager** - used to store user/password authentication details.
- **HTTP Header Manager** - used to store headers which will be used for making HTTP requests.
-- **User Defined Variables** - used to store following user defined parameters.
+- **User Defined Variables** - used to store following user defined parameters.
=================== ===============================================================================
**Name** **Description**
Summary
+++++++
-Multiple policies were executed in a multi threaded fashion for both stability and performance tests.
+Multiple policies were executed in a multi-threaded fashion for both stability and performance tests.
Both tests ran smoothly without any issues.
In order for PDP engines to fetch the resource details from AAI during runtime execution, we need to create dummy VNF & PNF entities in AAI.
In a real control loop flow, the entities in AAI will be either created during orchestration phase or provisioned in AAI separately.
-Download & execute the steps in postman collection for creating the entities along with it's dependencies.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+Download & execute the steps in postman collection for creating the entities along with its dependencies.
+The steps need to be performed sequentially one after another. And no input is required from user.
:download:`Create VNF & PNF in AAI <postman/create-vnf-pnf-aai.postman_collection.json>`
- Delete both VNF & PNF policies at the end.
Download & execute the steps in postman collection.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
:download:`Apex-PDP VNF & PNF Testing <postman/apex-pdp-vnf-pnf-testing.postman_collection.json>`
The 72 hour stability test of policy API has the goal of verifying the stability of running policy design API REST
service by ingesting a steady flow of transactions in a multi-threaded fashion to
-simulate multiple clients' behaviors.
+simulate multiple clients' behaviours.
All the transaction flows are initiated from a test client server running JMeter for the duration of 72 hours.
Setup Details
-------------
-The stability test was performed on a default ONAP OOM installation in the Intel Wind River Lab environment.
+The stability test was performed on a default ONAP OOM installation in the University of New Hampshire (UNH) Lab environment.
JMeter was installed on a separate VM to inject the traffic defined in the
`API stability script
<https://git.onap.org/policy/api/tree/testsuites/stability/src/main/resources/testplans/policy_api_stability.jmx>`_
The 72+ hours stability test will be running the following steps sequentially
in multi-threaded loops. Thread number is set to 5 to simulate 5 API clients'
-behaviors (they can be calling the same policy CRUD API simultaneously).
+behaviours (they can be calling the same policy CRUD API simultaneously).
Each thread creates a different version of the policy types and policies to not
interfere with one another while operating simultaneously. The point version
of each entity is set to the running thread number.
**API Test Flow (5 threads running the same steps in the same loop)**
-- Get Policy Metrics
- Create a new Monitoring Policy Type with Version 6.0.#
- Create a new Monitoring Policy Type with Version 7.0.#
- Create a new Optimization Policy Type with Version 6.0.#
- Get All Policy Types
- Get All Versions of the new Monitoring Policy Type
- Get Version 6.0.# of the new Monitoring Policy Type
-- Get Version 6.0.# of the new Optimzation Policy Type
+- Get Version 6.0.# of the new Optimization Policy Type
- Get Version 6.0.# of the new Guard Policy Type
- Get Version 6.0.# of the new Native APEX Policy Type
- Get Version 6.0.# of the new Native Drools Policy Type
- Get Version 6.0.# of the new Native XACML Policy Type
- Get the Latest Version of the New Monitoring Policy Type
+- Create Version 6.0.# of Node Template
- Create Monitoring Policy Ver 6.0.# w/Monitoring Policy Type Ver 6.0.#
- Create Monitoring Policy Ver 7.0.# w/Monitoring Policy Type Ver 7.0.#
- Create Optimization Policy Ver 6.0.# w/Optimization Policy Type Ver 6.0.#
- Create Native APEX Policy Ver 6.0.# w/Native APEX Policy Type Ver 6.0.#
- Create Native Drools Policy Ver 6.0.# w/Native Drools Policy Type Ver 6.0.#
- Create Native XACML Policy Ver 6.0.# w/Native XACML Policy Type Ver 6.0.#
+- Create Version 6.0.# of PNF Example Policy with Metadata
+- Get Node Template
+- Get All TCA Policies
+- Get All Versions of Monitoring Policy Type
- Get Version 6.0.# of the new Monitoring Policy
-- Get Version 6.0.# of the new Optimzation Policy
+- Get Version 6.0.# of the new Optimization Policy
- Get Version 6.0.# of the new Guard Policy
- Get Version 6.0.# of the new Native APEX Policy
- Get Version 6.0.# of the new Native Drools Policy
- Get the Latest Version of the new Monitoring Policy
- Delete Version 6.0.# of the new Monitoring Policy
- Delete Version 7.0.# of the new Monitoring Policy
-- Delete Version 6.0.# of the new Optimzation Policy
+- Delete Version 6.0.# of the new OptimizationPolicy
- Delete Version 6.0.# of the new Guard Policy
- Delete Version 6.0.# of the new Native APEX Policy
+- Delete Version 6.0.# of PNF Example Policy having Metadata
- Delete Version 6.0.# of the new Native Drools Policy
- Delete Version 6.0.# of the new Native XACML Policy
- Delete Monitoring Policy Type with Version 6.0.#
- Delete Native APEX Policy Type with Version 6.0.#
- Delete Native Drools Policy Type with Version 6.0.#
- Delete Native XACML Policy Type with Version 6.0.#
+- Delete Node Template
+- Get Policy Metrics
**TearDown Thread (will only be running after API Test Flow is completed)**
======================= ============= =========== =============================== =============================== ===============================
**Total # of requests** **Success %** **TPS** **Avg. time taken per request** **Min. time taken per request** **Max. time taken per request**
======================= ============= =========== =============================== =============================== ===============================
- 242277 100% 0.935 5340 ms 1 ms 736976 ms
+ 914881 100% 3.5 1413 ms 100 ms 22201 ms
======================= ============= =========== =============================== =============================== ===============================
-.. image:: api-s3p-results/api-s3p-jm-1_I.png
+.. image:: api-s3p-results/api-s3p-jm-1_J.png
**JMeter Results**
The following graphs show the response time distributions. The "Get Policy Types" API calls are the most expensive calls that
-average a 7 seconds plus response time.
+average a 13 seconds plus response time.
-.. image:: api-s3p-results/api-response-time-distribution_I.png
-.. image:: api-s3p-results/api-response-time-overtime_I.png
+.. image:: api-s3p-results/api-response-time-distribution_J.png
+.. image:: api-s3p-results/api-response-time-overtime_J.png
**Memory and CPU usage**
Setup Details
-------------
-The performance test was performed on a default ONAP OOM installation in the Intel Wind River Lab environment.
+The performance test was performed on a default ONAP OOM installation in the University of New Hampshire (UNH) Lab environment.
JMeter was installed on a separate VM to inject the traffic defined in the
-`API performace script
+`API performance script
<https://git.onap.org/policy/api/tree/testsuites/performance/src/main/resources/testplans/policy_api_performance.jmx>`_
with the following command:
---------
Performance test plan is the same as stability test plan above.
-Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviors at the same time) whereas reducing the test time down to 2.5 hours.
+Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviours at the same time) whereas reducing the test time down to 2.5 hours.
Run Test
--------
======================= ============= =========== =============================== =============================== ===============================
**Total # of requests** **Success %** **TPS** **Avg. time taken per request** **Min. time taken per request** **Max. time taken per request**
======================= ============= =========== =============================== =============================== ===============================
- 2822 100% 0.31 63794 ms 2 ms 1183376 ms
+ 10417 100% 1.1 17340 ms 100 ms 365982 ms
======================= ============= =========== =============================== =============================== ===============================
-.. image:: api-s3p-results/api-s3p-jm-2_I.png
+.. image:: api-s3p-results/api-s3p-jm-2_J.png
Test Results
------------
The following graphs show the response time distributions.
-.. image:: api-s3p-results/api-response-time-distribution_performance_I.png
-.. image:: api-s3p-results/api-response-time-overtime_performance_I.png
+.. image:: api-s3p-results/api-response-time-distribution_performance_J.png
+.. image:: api-s3p-results/api-response-time-overtime_performance_J.png
Execute policy-api testing
--------------------------
Download & execute the steps in postman collection for verifying policy-api component.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
`Policy Framework Lifecycle API <https://github.com/onap/policy-api/blob/master/postman/lifecycle-api-collection.json>`_
The CLAMP Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime
to coordinate life cycle management of Automation Composition instances.
-This document will serve as a guide to do smoke tests on the different usecases that are involved when
+This document will serve as a guide to do smoke tests on the different use cases that are involved when
working with the Participant protocol and outline how they operate.
It will also show a developer how to set up their environment for carrying out smoke tests on the participants.
**************
This section will show the developer how to set up their environment to start testing participants with some
-instructions on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a
+instructions on how to carry out the tests. There are several prerequisites. Note that this guide is written by a
Linux user - although the majority of the steps show will be exactly the same in Windows or other systems.
2.1 Prerequisites
- policy-api for communication between policy participant and policy-framework
In this setup guide, we will be setting up all the components technically required for a working convenient
-dev environment. We will not be setting up all of the participants - we will setup only the policy participant as an
+dev environment. We will not be setting up all the participants - we will setup only the policy participant as an
example.
2.2.1 MariaDB Setup
3.3 Participant Priming
=======================
-When a automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+When an automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
of each participant type mentioned in the Automation Composition Definition are sent to the participants.
Action: Invoke a REST API to prime acm type definitions and set values of common properties
3.4 Participant DePriming
=========================
-When a automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
+When an automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants
of each participant type mentioned in the Automation Composition Definition are deleted on participants.
Action: Invoke a REST API to deprime acm type definitions
- Undeployment of PMSH
Creation of the Automation Composition:
------------------------------
-A Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED".
+---------------------------------------
+An Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED".
-- Upload a TOSCA template from the POLICY GUI. The definitions includes a kubernetes participant and control loop elements that deploys and configures a microservice in the kubernetes cluster.
+- Upload a TOSCA template from the POLICY GUI. The definitions include a kubernetes participant and control loop elements that deploys and configures a microservice in the kubernetes cluster.
Automation Composition element for kubernetes participant includes a helm chart information of DCAE microservice and the element for Http Participant includes the configuration entity for the microservice.
:download:`Sample Tosca template <tosca/pairwise-testing.yml>`
- DCAE service PMSH is deployed in to the kubernetes cluster. PMSH pods are in RUNNING state.
`helm ls -n <namespace>` - The helm deployment of dcaegen2 service PMSH is listed.
- `kubectl get pod -n <namespace>` - The PMSH pods are deployed, up and Running.
+ `kubectl get pod -n <namespace>` - The PMSH pods are deployed, up and running.
- The subscription configuration for PMSH microservice from the TOSCA definitions are updated in the Consul server. The configuration can be verified on the Consul server UI `http://<CONSUL-SERVER_IP>/ui/#/dc1/kv/`
- Deployment/Undeployment of policies
Creation of the Automation Composition:
------------------------------
-A Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED".
+---------------------------------------
+An Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED".
-- Upload a TOSCA template from the POLICY GUI. The definitions includes a policy participant and a Automation Composition element that creates and deploys required policies. :download:`Sample Tosca template <tosca/pairwise-testing.yml>`
+- Upload a TOSCA template from the POLICY GUI. The definitions include a policy participant and an Automation Composition element that creates and deploys required policies. :download:`Sample Tosca template <tosca/pairwise-testing.yml>`
.. image:: images/cl-commission.png
Creation and deployment of policies:
----------------------
+------------------------------------
The Automation Composition state is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui. Verify the POLICY API endpoint for the creation of policy types that are defined in the TOSCA template. Verify the PAP endpoint for the deployment of policies.
.. image:: images/cl-passive.png
.. image:: images/cl-create.png
Undeployment and deletion of Policies:
----------------------
+--------------------------------------
The Automation Composition state is changed from "PASSIVE" to "UNINITIALISED" from the Policy Gui.
Verification:
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-.. _controlloop-s3p-label:
+.. _acm-s3p-label:
.. toctree::
:maxdepth: 2
-Policy Clamp Controlloop
-~~~~~~~~~~~~~~~~~~~~~~~~
+Policy Clamp Automation Composition
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Both the Performance and the Stability tests were executed by performing requests
-against controlloop components installed as docker images in local environment.
+against acm components installed as docker images in local environment.
Setup Details
+++++++++++++
-- Controlloop runtime component docker image is started and running.
+- acm runtime component docker image is started and running.
- Participant docker images policy-clamp-cl-pf-ppnt, policy-clamp-cl-http-ppnt, policy-clamp-cl-k8s-ppnt are started and running.
- Dmaap simulator for communication between components.
-- mariadb docker container for policy and controlloop database.
+- mariadb docker container for policy and clampacm database.
- policy-api for communication between policy participant and policy-framework
- Both tests were run via jMeter, which was installed on a separate VM.
-Stability Test of Controlloop components
-++++++++++++++++++++++++++++++++++++++++
+Stability Test of acm components
+++++++++++++++++++++++++++++++++
Test Plan
---------
- **Create Policy defaultDomain** - creates an operational policy using policy/api component
- **Delete Policy sampleDomain** - deletes the operational policy sampleDomain using policy/api component
-- **Commission Contorlloop definition** - commissions the controlloop definition in runtime
-- **Instantiate controlloop** - Instantiate the controlloop towards participants
-- **Check controlloop state** - check the current state of controlloop
-- **Change State to PASSIVE** - change the state of the controlloop to PASSIVE
-- **Check controlloop state** - check the current state of controlloop
-- **Change State to UNINITIALISED** - change the state of the controloop to UNINITIALISED
-- **Check controlloop state** - check the current state of controlloop
-- **Delete instantiated controlloop** - delete the instantiated controlloop from all participants
-- **Delete ControlLoop Definition** - delete the controlloop definition on runtime
+- **Commission Contorlloop definition** - commissions the acm definition in runtime
+- **Instantiate acm** - Instantiate the acm towards participants
+- **Check acm state** - check the current state of acm
+- **Change State to PASSIVE** - change the state of the acm to PASSIVE
+- **Check acm state** - check the current state of acm
+- **Change State to UNINITIALISED** - change the state of the ACM to UNINITIALISED
+- **Check acm state** - check the current state of acm
+- **Delete instantiated acm** - delete the instantiated acm from all participants
+- **Delete ACM Definition** - delete the acm definition on runtime
The following steps can be used to configure the parameters of test plan.
============================= ========================================================================
**Name** **Description**
============================= ========================================================================
- RUNTIME_HOST IP Address or host name of controlloop runtime component
- RUNTIME_PORT Port number of controlloop runtime components for making REST API calls
+ RUNTIME_HOST IP Address or host name of acm runtime component
+ RUNTIME_PORT Port number of acm runtime components for making REST API calls
POLICY_PARTICIPANT_HOST IP Address or host name of policy participant
POLICY_PARTICIPANT_HOST_PORT Port number of policy participant
============================= ========================================================================
.. Note::
.. container:: paragraph
-
- The assertions of state changes are not completely taken care of, as the stability is ran with controlloop componenets
+
+ The assertions of state changes are not completely taken care of, as the stability is ran with acm components
alone, and not including complete policy framework deployment, which makes it difficult for actual state changes from
PASSIVE to RUNNING etc to happen.
99992 100.00 % 0.00 % 192 ms
======================= ================= ================== ==================================
-**Controloop component Setup**
+**ACM component Setup**
================ ========================================================= =========================================== =========================
**CONTAINER ID** **IMAGE** **PORTS** **NAMES**
**JMeter Screenshot**
-.. image:: clamp-s3p-results/controlloop_stability_jmeter.png
+.. image:: clamp-s3p-results/acm_stability_jmeter.png
**JMeter Screenshot**
-.. image:: clamp-s3p-results/controlloop_stability_table.png
+.. image:: clamp-s3p-results/acm_stability_table.png
**Memory and CPU usage**
.. image:: clamp-s3p-results/Stability_after_stats.png
-Performance Test of Controlloop components
-++++++++++++++++++++++++++++++++++++++++++
+Performance Test of acm components
+++++++++++++++++++++++++++++++++++
Introduction
------------
-Performance test of Controlloop components has the goal of testing the min/avg/max processing time and rest call throughput for all the requests with multiple requests at the same time.
+Performance test of acm components has the goal of testing the min/avg/max processing time and rest call throughput for all the requests with multiple requests at the same time.
Setup Details
-------------
13809 100 % 0.00 % 206 ms
======================= ================= ================== ==================================
-**Controloop component Setup**
+**ACM component Setup**
================ ========================================================= =========================================== =========================
**CONTAINER ID** **IMAGE** **PORTS** **NAMES**
* You have copied the settings.xml from oparent to *~/.m2/* directory
* You have added settings to access the ONAP Nexus to your M2 configuration, see `Maven Settings Example <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_ (bottom of the linked page)
-The procedure documented in this article has been verified using Unbuntu 20.04 LTS VM.
+The procedure documented in this article has been verified using Ubuntu 20.04 LTS VM.
Cloning CLAMP automation composition and all dependency
*******************************************************
Assuming you have successfully built the codebase using the instructions above. There are two requirements for the Clamp automation composition component to run, one of them is a
running MariaDb database instance. The easiest way to do this is to run the docker image locally.
-An sql such as the one below can be used to build the SQL initialization. Create the *mariadb.sql* file in the directory *~/git*.
+A sql such as the one below can be used to build the SQL initialization. Create the *mariadb.sql* file in the directory *~/git*.
.. code-block:: SQL
command: /bin/sh -c "pip install --no-cache-dir requests && pip install --no-cache-dir simplejson && python -u /script/third_party_proxy.py -v true --port 8085 --root /thirdparty --proxyaddress third-party-proxy:8085"
-Run DMaaP simulator, and than run CLAMP Acm using java.
+Run DMaaP simulator, and then run CLAMP Acm using java.
-.. This work is licensed under a Creative Commons Attribution
+.. This work is licensed under a Creative Commons Attribution
.. 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
Make/Redeploy to run downgrade
-Check the tables to ensure the number records is the same.
+Check the tables to ensure the number of records is the same.
.. code::
:number-lines:
Make/Redeploy to run upgrade
-Check the tables to ensure the number records is the same.
+Check the tables to ensure the number of records is the same.
.. code::
:number-lines:
- 0900
.. note::
- The number of records added may vary depnding on the number of retries.
+ The number of records added may vary depending on the number of retries.
With addition of Postgres support to db-migrator, these tests can be also performed on a Postgres version of database.
In addition, scripts running the aforementioned scenarios can be found under `smoke-tests` folder on db-migrator code base.
* You have copied the settings.xml from oparent to *~/.m2/* directory
* You have added settings to access the ONAP Nexus to your M2 configuration, see `Maven Settings Example <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_ (bottom of the linked page)
-The procedure documented in this article has been verified to work on a MacBook laptop running macOS Mojave Version 10.14.6 and an Unbuntu 18.06 VM.
+The procedure documented in this article has been verified to work on a MacBook laptop running macOS Mojave Version 10.14.6 and an Ubuntu 18.06 VM.
Cloning All The Policy Repositories
***********************************
policy-gui-acm-smoke.rst
db-migrator-smoke.rst
- cl-participants-smoke.rst
+ acm-participants-smoke.rst
clamp-smoke.rst
clamp-cl-participant-protocol-smoke.rst
policy-participant-smoke.rst
Generating Swagger Documentation
********************************
The `Policy Parent Integration POM <https://github.com/onap/policy-parent/blob/master/integration/pom.xml>`_ contains a *generateSwaggerDocs* profile. This
-profile can be activated on any module that has a Swagger endopint. When active, this profile creates a tarball in Nexus with the name
-*<project-artifactId>-swagger-docs.tar.gz*. The tarball contains the fillowing files:
+profile can be activated on any module that has a Swagger endpoint. When active, this profile creates a tarball in Nexus with the name
+*<project-artifactId>-swagger-docs.tar.gz*. The tarball contains the following files:
.. code-block:: bash
See the `CLAMP runtime POM <https://github.com/onap/policy-clamp/blob/master/runtime/pom.xml>`_ for an example of the usage of this property.
-2. Unit tests are being executed in the build, in other wirds when the *skipTests* flag is *false*.
+2. Unit tests are being executed in the build, in other words when the *skipTests* flag is *false*.
You **must** create a unit test in your module that generates the following file:
Specifying a local configuration file
+++++++++++++++++++++++++++++++++++++
-You may specify a local configuration file instead of *src/test/resources/simParameters.json* on the command line or as an arument in the run configuration in eclipse:
+You may specify a local configuration file instead of *src/test/resources/simParameters.json* on the command line or as an argument in the run configuration in eclipse:
.. code-block:: json
Policy Distribution Smoke Test
################################
-The policy-distribution smoke testing is executed against a custom ONAP docker installation as defined in the "policy/docker/csit/docker-compose-distribution-smoke.yml"
+The policy-distribution smoke testing is executed against a custom ONAP docker installation as defined in the docker compose file in "policy/docker/csit/".
+The policy-distribution configuration file is located in "docker/csit/config/distribution/".
This test verifies the execution of the REST api's exposed by the component to make sure the CSAR Decoding and Forwarding works as expected.
General Setup
- Policy Drools-PDP to deploy & undeploy policies. And send heartbeats to PAP.
- Policy Xacml-PDP to deploy & undeploy policies. And send heartbeats to PAP.
-- Policy Distribution to test the Decoding and Farwarding functions.
+- Policy Distribution to test the Decoding and Forwarding functions.
-Use this script to easly bring down the containers :
+Use this script to easily bring down the containers :
.. code-block:: bash
[{"policy-type":"onap.policies.native.Apex","policy-type-version":"1.0.0","policy-id":"operational.apex.sampledomain","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0},{"policy-type":"onap.policies.Naming","policy-type-version":"1.0.0","policy-id":"SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0}]
Or download & execute the steps in postman collection for verifying policy-pap component.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
`Policy Framework Administration API <https://github.com/onap/policy-pap/blob/master/postman/pap-api-collection.json>`_
- vCPE success scenario
- vCPE failure scenario (failure returned by simulated APPC recipient through DMaaP).
- vDNS success scenario.
-- vDNS failure scenario (failure by introducing in the DCAE ONSET a non-existant vserver-name reference).
+- vDNS failure scenario (failure by introducing in the DCAE ONSET a non-existent vserver-name reference).
- vFirewall success scenario.
Five threads ran in parallel, one for each scenario, back to back with no pauses. The transactions were initiated
+++++++++++++
- Policy-PAP along with all policy components deployed as part of a full ONAP OOM deployment.
-- A second instance of APEX-PDP is spun up in the setup. Update the configuration file(OnapPfConfig.json) such that the PDP can register to the new group created by PAP in the tests.
+- A second instance of APEX-PDP is spun up in the setup. Update the configuration file (OnapPfConfig.json) such that the PDP can register to the new group created by PAP in the tests.
- Both tests were run via jMeter, which was installed on a separate VM.
Stability Test of PAP
As part of the OOM deployment, another APEX-PDP pod is spun up with the pdpGroup name specified as 'sampleGroup'.
After creating the new group called 'sampleGroup' as part of the test, a time delay of 2 minutes is added,
so that the pdp is registered to the newly created group.
- This has resulted in a spike in the Average time taken per request. But, this is required to make proper assertions,
+ This has resulted in a spike in the Average time taken per request. But this is required to make proper assertions,
and also for the consolidated health check.
**Test Statistics**
In order to test policy-pap, we need to use policy-api component to create the policies.
Download & execute the steps in postman collection for creating policies.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
`Policy Framework Lifecycle API <https://github.com/onap/policy-api/blob/master/postman/lifecycle-api-collection.json>`_
Execute policy-pap testing
--------------------------
Download & execute the steps in postman collection for verifying policy-pap component.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
`Policy Framework Administration API <https://github.com/onap/policy-pap/blob/master/postman/pap-api-collection.json>`_
In order for PDP engines to fetch the resource details from AAI during runtime execution, we need to create dummy VNF & PNF entities in AAI.
In a real Automation Composition flow, the entities in AAI will be either created during orchestration phase or provisioned in AAI separately.
-Download & execute the steps in postman collection for creating the entities along with it's dependencies.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+Download & execute the steps in postman collection for creating the entities along with its dependencies.
+The steps need to be performed sequentially one after another. And no input is required from user.
:download:`Create VNF & PNF in AAI <postman/create-vnf-pnf-aai.postman_collection.json>`
- Delete both VNF & PNF policies at the end.
Download & execute the steps in postman collection.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
:download:`Apex-PDP VNF & PNF Testing <postman/apex-pdp-vnf-pnf-testing.postman_collection.json>`
- Delete both VNF & PNF policies at the end.
Download & execute the steps in postman collection.
-The steps needs to be performed sequentially one after another. And no input is required from user.
+The steps need to be performed sequentially one after another. And no input is required from user.
:download:`Drools-PDP VNF & PNF Testing <postman/drools-pdp-vnf-pnf-testing.postman_collection.json>`
2. Setup Guide
**************
-This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. The IDE used in the examples here is Intellij but most or all of what is described should be the same across IDEs.
+This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. The IDE used in the examples here is Intellij but most or all of what is described should be the same across IDEs.
2.1 Prerequisites
=================
2.3.8 Automation Composition GUI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-At this point, all of the components required to test out the acm gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
+At this point, all of the components required to test out the acm gui are running. We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI.
Firstly, go to the GUI repo and navigate to "gui-clamp/ui-react". To setup for development, we must install the dependencies of the GUI. We can do this using the npm package manager. In the directory, simply run:
.. image:: images/gui/PolicySuccess.png
-Following the same procedure as changeing the state to PASSIVE, we can then change to UNINITIALISED. This deletes the policies and policy types through the policy api and changes the overall state of the loop. we can then delete it from the Manage Instances table by clicking on Delete.
+Following the same procedure as changing the state to PASSIVE, we can then change to UNINITIALISED. This deletes the policies and policy types through the policy api and changes the overall state of the loop. we can then delete it from the Manage Instances table by clicking on Delete.
Decommissioning
===============
2. Setup Guide
**************
-This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems.
+This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems.
2.1 Prerequisites
=================
Creation of ACM:
************************
-A ACM is created by commissioning a Tosca template with ACM definitions and instantiating the ACM with the state "UNINITIALISED".
+An ACM is created by commissioning a Tosca template with ACM definitions and instantiating the ACM with the state "UNINITIALISED".
Using postman, commission a TOSCA template and instantiate using the following template:
:download:`Tosca Service Template <tosca/tosca_service_template_pptnt_smoke.yaml>`
Summary
=======
-The Performance test was executed, and the result analyzed, via:
+The Performance test was executed, and the result analysed, via:
.. code-block:: bash
The test was run via jmeter, which was installed on the same VM.
Running jmeter and ONAP OOM on the same VM may adversely impact the performance of the XACML-PDP being tested.
-Due to the minimal nauture of this setup, the K8S cluster became overloaded on a couple of occasions during the test.
+Due to the minimal nature of this setup, the K8S cluster became overloaded on a couple of occasions during the test.
This resulted in a small number of errors and a greater maximum transaction time than normal.
Summary
<parent>
<groupId>org.onap.policy.parent</groupId>
<artifactId>policy-parent</artifactId>
- <version>3.5.2-SNAPSHOT</version>
+ <version>3.5.3-SNAPSHOT</version>
</parent>
<artifactId>integration</artifactId>
<packaging>pom</packaging>
<properties>
<java.version>11</java.version>
<!-- NOTE: For RELEASE/SNAPSHOT always set to the project version -->
- <version.parent.resources>3.5.1</version.parent.resources>
+ <version.parent.resources>3.5.2</version.parent.resources>
<version.logback>1.2.10</version.logback>
<version.dmaap>1.1.12</version.dmaap>
<version.powermock>2.0.9</version.powermock>
<version.eclipselink>2.7.8</version.eclipselink>
<version.drools>7.66.0.Final</version.drools>
<version.jersey>2.34</version.jersey>
- <version.jackson>2.12.3</version.jackson>
+ <version.jackson>2.12.6</version.jackson>
+ <version.jackson.databind>2.12.6.1</version.jackson.databind>
<version.ccsdk>1.1.5</version.ccsdk>
- <version.swagger>1.6.2</version.swagger>
+ <version.swagger>1.6.6</version.swagger>
<version.javax.bind>2.3.1</version.javax.bind>
<version.javax.json>1.1.4</version.javax.json>
<version.netty>4.1.70.Final</version.netty>
<version.jakarta-api>2.0.2</version.jakarta-api>
<version.io.micrometer>1.7.3</version.io.micrometer>
<version.io.prometheus>0.11.0</version.io.prometheus>
- <version.postgres>42.3.1</version.postgres>
+ <version.postgres>42.3.3</version.postgres>
<jacoco.dataFile>${project.basedir}/../target/code-coverage/jacoco-ut.exec</jacoco.dataFile>
<repo.npm>https://nexus3.onap.org/repository/npm.public/npm/-/</repo.npm>
<docker.pull.registry>nexus3.onap.org:10001</docker.pull.registry>
</dependency>
<!-- Jackson - needed by glassfish jersey -->
+ <dependency>
+ <groupId>com.fasterxml.jackson.core</groupId>
+ <artifactId>jackson-core</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.core</groupId>
+ <artifactId>jackson-databind</artifactId>
+ <version>${version.jackson.databind}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.core</groupId>
+ <artifactId>jackson-annotations</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
<dependency>
<groupId>com.fasterxml.jackson.module</groupId>
<artifactId>jackson-module-jaxb-annotations</artifactId>
<version>${version.jackson}</version>
</dependency>
+ <dependency>
+ <groupId>com.fasterxml.jackson.module</groupId>
+ <artifactId>jackson-module-jsonSchema</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.module</groupId>
+ <artifactId>jackson-module-parameter-names</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <!-- Overriding this one breaks drools-applicaiotns -->
+ <!--dependency>
+ <groupId>com.fasterxml.jackson.module</groupId>
+ <artifactId>jackson-module-kotlin</artifactId>
+ <version>${version.jackson}</version>
+ </dependency-->
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.module</groupId>
+ <artifactId>jackson-module-scala_2.12</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.dataformat</groupId>
+ <artifactId>jackson-dataformat-yaml</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.dataformat</groupId>
+ <artifactId>jackson-dataformat-xml</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.dataformat</groupId>
+ <artifactId>jackson-dataformat-csv</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.datatype</groupId>
+ <artifactId>jackson-datatype-jdk8</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.datatype</groupId>
+ <artifactId>jackson-datatype-jsr310</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.datatype</groupId>
+ <artifactId>jackson-datatype-joda</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.jaxrs</groupId>
+ <artifactId>jackson-jaxrs-base</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
+ <dependency>
+ <groupId>com.fasterxml.jackson.jaxrs</groupId>
+ <artifactId>jackson-jaxrs-json-provider</artifactId>
+ <version>${version.jackson}</version>
+ </dependency>
+
<!-- Jersey -->
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>${version.jersey}</version>
- <exclusions>
- <exclusion>
- <groupId>com.fasterxml.jackson.module</groupId>
- <artifactId>jackson-module-jaxb-annotations</artifactId>
- </exclusion>
- </exclusions>
</dependency>
<dependency>
<groupId>org.onap.dmaap.messagerouter.dmaapclient</groupId>
<artifactId>dmaapClient</artifactId>
<version>${version.dmaap}</version>
+ <exclusions>
+ <exclusion>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-log4j12</artifactId>
+ </exclusion>
+ <exclusion>
+ <groupId>log4j</groupId>
+ <artifactId>log4j</artifactId>
+ </exclusion>
+ <exclusion>
+ <artifactId>apache-log4j-extras</artifactId>
+ <groupId>log4j</groupId>
+ </exclusion>
+ </exclusions>
</dependency>
<!-- CDS dependencies -->
</parent>
<groupId>org.onap.policy.parent</groupId>
<artifactId>policy-parent</artifactId>
- <version>3.5.2-SNAPSHOT</version>
+ <version>3.5.3-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
--- /dev/null
+distribution_type: 'maven'
+version: '3.5.2'
+project: 'policy-parent'
+log_dir: 'policy-parent-maven-stage-master/1036/'
<parent>
<groupId>org.onap.policy.parent</groupId>
<artifactId>policy-parent</artifactId>
- <version>3.5.2-SNAPSHOT</version>
+ <version>3.5.3-SNAPSHOT</version>
</parent>
<artifactId>policy-parent-resources</artifactId>
major=3
minor=5
-patch=2
+patch=3
base_version=${major}.${minor}.${patch}
Code Review / policy / parent.git / commitdiff
