--- /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-acm:
-
-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
"/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
Code Review / policy / parent.git / commitdiff
