summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorLiam Fallon <liam.fallon@est.tech>2022-03-31 16:51:37 +0000
committerGerrit Code Review <gerrit@onap.org>2022-03-31 16:51:37 +0000
commita4ae5b14800978d977677c5db11dc368fc995a26 (patch)
tree18a13d47ae5da6cb89e86307bcb51b4dabd8ac00 /docs
parent5ed76e0ff3fb35095ada412b21a944dcf80f75c6 (diff)
parent911e23fcbd06bf3e18724c055da8f808cfd2d905 (diff)
Merge "Rename Controlloop to Automation Composition"
Diffstat (limited to 'docs')
-rw-r--r--docs/development/devtools/clamp-dcae.rst24
-rw-r--r--docs/development/devtools/clamp-policy.rst68
-rw-r--r--docs/development/devtools/policy-cds.rst4
3 files changed, 37 insertions, 59 deletions
diff --git a/docs/development/devtools/clamp-dcae.rst b/docs/development/devtools/clamp-dcae.rst
index c5701084..679db69d 100644
--- a/docs/development/devtools/clamp-dcae.rst
+++ b/docs/development/devtools/clamp-dcae.rst
@@ -11,8 +11,8 @@ CLAMP <-> Dcae
~~~~~~~~~~~~~~
The pairwise testing is executed against a default ONAP installation in the OOM.
-CLAMP-Control loop interacts with DCAE to deploy dcaegen2 services like PMSH.
-This test verifies the interaction between DCAE and controlloop works as expected.
+CLAMP-Automation Composition interacts with DCAE to deploy dcaegen2 services like PMSH.
+This test verifies the interaction between DCAE and clamp-acm works as expected.
General Setup
*************
@@ -30,7 +30,7 @@ The ONAP components used during the pairwise tests are:
- CLAMP control loop runtime, policy participant, kubernetes participant.
- DCAE for running dcaegen2-service via kubernetes participant.
- ChartMuseum service from platform, initialised with DCAE helm charts.
-- DMaaP for the communication between Control loop runtime and participants.
+- DMaaP for the communication between Automation Composition runtime and participants.
- Policy Gui for instantiation and commissioning of control loops.
@@ -53,23 +53,23 @@ The test set focused on the following use cases:
- Deployment and Configuration of DCAE microservice PMSH
- Undeployment of PMSH
-Creation of the Control Loop:
+Creation of the Automation Composition:
-----------------------------
-A Control Loop is created by commissioning a Tosca template with Control loop definitions and instantiating the Control Loop with the state "UNINITIALISED".
+A 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.
- Control loop 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.
+ 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>`
.. image:: images/cl-commission.png
Verification: The template is commissioned successfully without errors.
-- Instantiate the commissioned Control loop definitions from the Policy Gui under 'Instantiation Management'.
+- Instantiate the commissioned Automation Composition definitions from the Policy Gui under 'Instantiation Management'.
.. image:: images/create-instance.png
- Update instance properties of the Control Loop Elements if required.
+ Update instance properties of the Automation Composition Elements if required.
.. image:: images/update-instance.png
@@ -80,7 +80,7 @@ A Control Loop is created by commissioning a Tosca template with Control loop de
Deployment and Configuration of DCAE microservice (PMSH):
---------------------------------------------------------
-The Control Loop state is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui. The kubernetes participant deploys the PMSH helm chart from the DCAE chartMuseum server.
+The Automation Composition state is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui. The kubernetes participant deploys the PMSH helm chart from the DCAE chartMuseum server.
.. image:: images/cl-passive.png
@@ -92,14 +92,14 @@ Verification:
- 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/`
-- The overall state of the Control Loop is changed to "PASSIVE" in the Policy Gui.
+- The overall state of the Automation Composition is changed to "PASSIVE" in the Policy Gui.
.. image:: images/cl-create.png
Undeployment of DCAE microservice (PMSH):
-----------------------------------------
-The Control Loop state is changed from "PASSIVE" to "UNINITIALISED" from the Policy Gui.
+The Automation Composition state is changed from "PASSIVE" to "UNINITIALISED" from the Policy Gui.
.. image:: images/cl-uninitialise.png
@@ -107,7 +107,7 @@ Verification:
- The kubernetes participant uninstall the DCAE PMSH helm chart from the kubernetes cluster. The pods are removed from the cluster.
-- The overall state of the Control Loop is changed to "UNINITIALISED" in the Policy Gui.
+- The overall state of the Automation Composition is changed to "UNINITIALISED" in the Policy Gui.
.. image:: images/cl-uninitialised-state.png
diff --git a/docs/development/devtools/clamp-policy.rst b/docs/development/devtools/clamp-policy.rst
index a0e11152..50fb10cf 100644
--- a/docs/development/devtools/clamp-policy.rst
+++ b/docs/development/devtools/clamp-policy.rst
@@ -11,8 +11,8 @@ CLAMP <-> Policy Core
~~~~~~~~~~~~~~~~~~~~~
The pairwise testing is executed against a default ONAP installation in the OOM.
-CLAMP-Control loop interacts with Policy framework to create and deploy policies.
-This test verifies the interaction between policy and controlloop works as expected.
+CLAMP-Automation Composition interacts with Policy framework to create and deploy policies.
+This test verifies the interaction between policy and clamp-acm works as expected.
General Setup
*************
@@ -27,12 +27,12 @@ The worker VM hosting the policy components has the following spec:
The ONAP components used during the pairwise tests are:
-- CLAMP control loop runtime, policy participant, kubernetes participant.
-- DMaaP for the communication between Control loop runtime and participants.
+- CLAMP Automation Composition runtime, policy participant, kubernetes participant.
+- DMaaP for the communication between Automation Composition runtime and participants.
- Policy API to create (and delete at the end of the tests) policies for each
scenario under test.
- Policy PAP to deploy (and undeploy at the end of the tests) policies for each scenario under test.
-- Policy Gui for instantiation and commissioning of control loops.
+- Policy Gui for instantiation and commissioning of Automation Compositions.
Testing procedure
@@ -43,32 +43,32 @@ The test set focused on the following use cases:
- creation/Deletion of policies
- Deployment/Undeployment of policies
-Creation of the Control Loop:
+Creation of the Automation Composition:
-----------------------------
-A Control Loop is created by commissioning a Tosca template with Control loop definitions and instantiating the Control Loop with the state "UNINITIALISED".
+A 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 control loop 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 includes a policy participant and a Automation Composition element that creates and deploys required policies. :download:`Sample Tosca template <tosca/pairwise-testing.yml>`
.. image:: images/cl-commission.png
Verification: The template is commissioned successfully without errors.
-- Instantiate the commissioned Control loop from the Policy Gui under 'Instantiation Management'.
+- Instantiate the commissioned Automation Composition from the Policy Gui under 'Instantiation Management'.
.. image:: images/create-instance.png
- Update instance properties of the Control Loop Elements if required.
+ Update instance properties of the Automation Composition Elements if required.
.. image:: images/update-instance.png
- Verification: The control loop is created with default state "UNINITIALISED" without errors.
+ Verification: The Automation Composition is created with default state "UNINITIALISED" without errors.
.. image:: images/cl-instantiation.png
-Creation of policies:
+Creation and deployment of policies:
---------------------
-The Control Loop 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.
+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
@@ -77,48 +77,26 @@ Verification:
- The policy types defined in the tosca template is created by the policy participant and listed in the policy Api.
Policy Api endpoint: `<https://<POLICY-API-IP>/policy/api/v1/policytypes>`
-- The overall state of the Control Loop is changed to "PASSIVE" in the Policy Gui.
-
-.. image:: images/cl-create.png
-
-
-Deployment of policies:
------------------------
-The Control Loop state is changed from "PASSIVE" to "RUNNING" from the Policy Gui.
-
-.. image:: images/cl-running.png
-
-Verification:
-
-- The policy participant deploys the policies of Tosca Control loop elements in Policy PAP for all the pdp groups.
+- The policy participant deploys the policies of Tosca Automation Composition elements in Policy PAP for all the pdp groups.
Policy PAP endpoint: `<https://<POLICY-PAP-IP>/policy/pap/v1/pdps>`
-- The overall state of the Control Loop is changed to "RUNNING" in the Policy Gui.
+- The overall state of the Automation Composition is changed to "PASSIVE" in the Policy Gui.
-.. image:: images/cl-running-state.png
+.. image:: images/cl-create.png
-Deletion of Policies:
+Undeployment and deletion of Policies:
---------------------
-The Control Loop state is changed from "RUNNING" to "PASSIVE" from the Policy Gui.
+The Automation Composition state is changed from "PASSIVE" to "UNINITIALISED" from the Policy Gui.
Verification:
-- The policy participant deletes the created policy types which can be verified on the Policy Api. The policy types created as part of the control loop should not be listed on the Policy Api.
+- The policy participant undeploys the policies of the Automation Composition element from the pdp groups. The policies deployed as part of the Automation Composition should not be listed on the Policy PAP.
+ Policy PAP endpoint: `<https://<POLICY-PAP-IP>/policy/pap/v1/pdps>`
+
+- The policy participant deletes the created policy types which can be verified on the Policy Api. The policy types created as part of the Automation Composition should not be listed on the Policy Api.
Policy Api endpoint: `<https://<POLICY-API-IP>/policy/api/v1/policytypes>`
-- The overall state of the Control Loop is changed to "PASSIVE" in the Policy Gui.
+- The overall state of the Automation Composition is changed to "PASSIVE" in the Policy Gui.
.. image:: images/cl-create.png
-Undeployment of policies:
--------------------------
-The Control Loop state is changed from "PASSIVE" to "UNINITIALISED" from the Policy Gui.
-
-Verification:
-
-- The policy participant undeploys the policies of the control loop element from the pdp groups. The policies deployed as part of the control loop should not be listed on the Policy PAP.
- Policy PAP endpoint: `<https://<POLICY-PAP-IP>/policy/pap/v1/pdps>`
-
-- The overall state of the Control Loop is changed to "UNINITIALISED" in the Policy Gui.
-
-.. image:: images/cl-uninitialised-state.png
diff --git a/docs/development/devtools/policy-cds.rst b/docs/development/devtools/policy-cds.rst
index b21a16b1..35331a2f 100644
--- a/docs/development/devtools/policy-cds.rst
+++ b/docs/development/devtools/policy-cds.rst
@@ -11,7 +11,7 @@ Policy <-> CDS
~~~~~~~~~~~~~~
The pairwise testing is executed against a default ONAP installation as per OOM charts.
-Apex-PDP or Drools-PDP engine interacts with CDS to execute a control loop action.
+Apex-PDP or Drools-PDP engine interacts with CDS to execute an Automation Composition action.
This test verifies the interaction between Policy and CDS to make sure the contract works as expected.
General Setup
@@ -48,7 +48,7 @@ The test set is focused on the following use cases:
Creation of VNF & PNF in AAI
----------------------------
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.
+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.