Fix documentation warnings

Some remaining warnings in the documentaiton build ar fixed.

Issue-ID: POLICY-3710
Change-Id: I4d41c3db48d4384cd03f4e9205cf0dcad6f684d4
Signed-off-by: liamfallon <liam.fallon@est.tech>

diff --git a/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst b/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst
index b30dff3..20f60b6 100644 (file)
--- a/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst
+++ b/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst
@@ -35,7 +35,8 @@ Prerequisites for using Kubernetes participant in Istanbul version:
 .. image:: ../../images/participants/k8s-participant.png
 
 Defining a TOSCA CL definition for kubernetes participant:
 .. image:: ../../images/participants/k8s-participant.png
 
 Defining a TOSCA CL definition for 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 *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.
 

diff --git a/docs/clamp/controlloop/design-impl/participants/policy-framework-participant.rst b/docs/clamp/controlloop/design-impl/participants/policy-framework-participant.rst
index 99f2981..56b2844 100644 (file)
--- a/docs/clamp/controlloop/design-impl/participants/policy-framework-participant.rst
+++ b/docs/clamp/controlloop/design-impl/participants/policy-framework-participant.rst
@@ -42,7 +42,7 @@ The PDP Statistics API is used to get statistics for statistics report from the
 Policy Type and Policy References
 +++++++++++++++++++++++++++++++++
 
 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 Control Loop Element type references to specify what policy type and policy should be used by a Policy Control Loop 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 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.
 


@@ -51,19 +51,29 @@ Policy Type References
 
 The Policy Participant uses the following steps for Policy Type References:
 
 
 The Policy Participant uses the following steps for Policy Type References:
 

-    1. The Policy Participant reads the Policy Type ID from the policyType property specified for the Control Loop Element
-    2. 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 The CLAMP Control Loop Participant Protocol#Messages.
-        a. 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
-        b. If the Policy Type has not been specified, the Participant checks that the Policy Type is already in the Policy framework. If the Policy Type already exists, execution proceeds, otherwise an error is reported
+#. The Policy Participant reads the Policy Type ID from the policyType property specified for the Control Loop 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`.
+
+  #. 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.
+
+  #. If the Policy Type has not been specified, the Participant checks that the Policy Type is already in the Policy
+     framework. If the Policy Type already exists, execution proceeds, otherwise an error is reported.

 
 Policy References
 *****************
 
 The Policy Participant uses the following steps for Policy References:
 
 
 Policy References
 *****************
 
 The Policy Participant uses the following steps for Policy References:
 

-    1. The Policy Participant reads the Policy ID from the policyId property specified for the Control Loop Element
-    2. It checks if a Policy with that Policy ID has been specified in the ToscaServiceTemplateFragment field in the ControLoopElement definition in the 
-       ControlLoopUpdate message, see The CLAMP Control Loop Participant Protocol#Messages.
-        a. 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
-        b. If the Policy has not been specified, the Participant checks that the Policy is already in the Policy framework. If the Policy already exists, execution proceeds, otherwise an error is reported
\ No newline at end of file
+#. The Policy Participant reads the Policy ID from the policyId property specified for the Control Loop 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`.
+
+  #. 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.
+
+  #. If the Policy has not been specified, the Participant checks that the Policy is already in the Policy framework. If
+     the Policy already exists, execution proceeds, otherwise an error is reported.
\ No newline at end of file

diff --git a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
index 98d7fcd..67005fa 100644 (file)
--- a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
+++ b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst
@@ -1,9 +1,12 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. _clamp-gui-controlloop-smoke-tests:
+.. _clamp-participant-protocol-smoke-tests:
+

 CLAMP Participant Protocol Smoke Tests
 CLAMP Participant Protocol Smoke Tests

----------------------------
+--------------------------------------
+

 1. Introduction
 ***************
 1. Introduction
 ***************

+

 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.
 This document will serve as a guide to do smoke tests on the different usecases that are involved when
 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.
 This document will serve as a guide to do smoke tests on the different usecases that are involved when


@@ -12,10 +15,14 @@ It will also show a developer how to set up their environment for carrying out s
 
 2. Setup Guide
 **************
 
 2. Setup Guide
 **************

-This section will show the developer how to set up their environment to start testing participants 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 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
+Linux user - although the majority of the steps show will be exactly the same in Windows or other systems.

 
 2.1 Prerequisites
 =================
 
 2.1 Prerequisites
 =================

+

 - Java 11
 - Docker
 - Maven 3
 - Java 11
 - Docker
 - Maven 3


@@ -24,56 +31,75 @@ This section will show the developer how to set up their environment to start te
 
 2.2 Setting up the components
 =============================
 
 2.2 Setting up the components
 =============================

+

 - Controlloop 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.
 - policy-api for communication between policy participant and policy-framework
 - Controlloop 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.
 - 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 example.
+
+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
+example.

 
 2.2.1 MariaDB Setup
 ===================
 
 2.2.1 MariaDB Setup
 ===================

+

 We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.
 We will be using Docker to run our mariadb instance. It will have a total of two databases running in it.

+

 - controlloop: the runtime-controlloop db
 - policyadmin: the policy-api db
 
 3. Running Tests of protocol dialogues
 **************************************
 - controlloop: the runtime-controlloop db
 - policyadmin: the policy-api db
 
 3. Running Tests of protocol dialogues
 **************************************

-lloop type definitions and common property values for participant types
+
+loop type definitions and common property values for participant types.
+

 In this section, we will run through the functionalities mentioned at the start of this document is section 1. Each functionality will be tested and we will confirm that they were carried out successfully. There is a tosca service template that can be used for this test
 :download:`Tosca Service Template <tosca/tosca-for-gui-smoke-tests.yaml>`
 
 3.1 Participant Registration
 ============================
 In this section, we will run through the functionalities mentioned at the start of this document is section 1. Each functionality will be tested and we will confirm that they were carried out successfully. There is a tosca service template that can be used for this test
 :download:`Tosca Service Template <tosca/tosca-for-gui-smoke-tests.yaml>`
 
 3.1 Participant Registration
 ============================

+

 Action: Bring up the participant
 Action: Bring up the participant

+

 Test result:
 Test result:

+

 - Observe PARTICIPANT_REGISTER going from participant to runtime
 - Observe PARTICIPANT_REGISTER_ACK going from runtime to participant
 - Observe PARTICIPANT_UPDATE going from runtime to participant
 
 3.2 Participant Deregistration
 ==============================
 - Observe PARTICIPANT_REGISTER going from participant to runtime
 - Observe PARTICIPANT_REGISTER_ACK going from runtime to participant
 - Observe PARTICIPANT_UPDATE going from runtime to participant
 
 3.2 Participant Deregistration
 ==============================

+

 Action: Bring down the participant
 Test result:
 Action: Bring down the participant
 Test result:

+

 - Observe PARTICIPANT_DEREGISTER going from participant to runtime
 - Observe PARTICIPANT_DEREGISTER_ACK going from runtime to participant
 
 3.3 Participant Priming
 =======================
 - Observe PARTICIPANT_DEREGISTER going from participant to runtime
 - Observe PARTICIPANT_DEREGISTER_ACK going from runtime to participant
 
 3.3 Participant 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.
 Action: Invoke a REST API to prime controlloop type definitions and set values of common properties
 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.
 Action: Invoke a REST API to prime controlloop type definitions and set values of common properties

+

 Test result:
 Test result:

+

 - Observe PARTICIPANT_UPDATE going from runtime to participant with controlloop type definitions and common property values for participant types
 - Observe that the controlloop type definitions and common property values for participant types are stored on ParticipantHandler
 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
 
 3.4 Participant DePriming
 =========================
 - Observe PARTICIPANT_UPDATE going from runtime to participant with controlloop type definitions and common property values for participant types
 - Observe that the controlloop type definitions and common property values for participant types are stored on ParticipantHandler
 - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant
 
 3.4 Participant DePriming
 =========================

+

 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.
 Action: Invoke a REST API to deprime controlloop type definitions
 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.
 Action: Invoke a REST API to deprime controlloop type definitions

+

 Test result:
 Test result:

+

 - If controlloop instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission controlloop type definition"
 - If no controlloop instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
 - Observe that the controlloop type definitions and common property values for participant types are removed on ParticipantHandler
 - If controlloop instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission controlloop type definition"
 - If no controlloop instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null
 - Observe that the controlloop type definitions and common property values for participant types are removed on ParticipantHandler


@@ -81,9 +107,12 @@ Test result:
 
 3.5 Control Loop Update
 =======================
 
 3.5 Control Loop Update
 =======================

+

 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Trigger controlloop instantiation from GUI
 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Trigger controlloop instantiation from GUI

+

 Test result:
 Test result:

+

 - Observe CONTROL_LOOP_UPDATE going from runtime to participant
 - Observe that the controlloop type instances and respective property values for participant types are stored on ControlLoopHandler
 - Observe that the controlloop state is UNINITIALISED
 - Observe CONTROL_LOOP_UPDATE going from runtime to participant
 - Observe that the controlloop type instances and respective property values for participant types are stored on ControlLoopHandler
 - Observe that the controlloop state is UNINITIALISED


@@ -91,9 +120,12 @@ Test result:
 
 3.6 Control Loop state change to PASSIVE
 ========================================
 
 3.6 Control Loop state change to PASSIVE
 ========================================

+

 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to PASSIVE
 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to PASSIVE

+

 Test result:
 Test result:

+

 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is PASSIVE
 - Observe that the controlloop state is PASSIVE
 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is PASSIVE
 - Observe that the controlloop state is PASSIVE


@@ -101,9 +133,12 @@ Test result:
 
 3.7 Control Loop state change to RUNNING
 ========================================
 
 3.7 Control Loop state change to RUNNING
 ========================================

+

 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to RUNNING
 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to RUNNING

+

 Test result:
 Test result:

+

 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is RUNNING
 - Observe that the controlloop state is RUNNING
 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is RUNNING
 - Observe that the controlloop state is RUNNING


@@ -111,9 +146,12 @@ Test result:
 
 3.8 Control Loop state change to PASSIVE
 ========================================
 
 3.8 Control Loop state change to PASSIVE
 ========================================

+

 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to PASSIVE
 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to PASSIVE

+

 Test result:
 Test result:

+

 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is PASSIVE
 - Observe that the controlloop state is PASSIVE
 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is PASSIVE
 - Observe that the controlloop state is PASSIVE


@@ -121,9 +159,12 @@ Test result:
 
 3.9 Control Loop state change to UNINITIALISED
 ==============================================
 
 3.9 Control Loop state change to UNINITIALISED
 ==============================================

+

 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to UNINITIALISED
 Control Loop Update handles creation, change, and deletion of control loops on participants.
 Action: Change state of the controlloop to UNINITIALISED

+

 Test result:
 Test result:

+

 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is UNINITIALISED
 - Observe that the controlloop state is UNINITIALISED
 - Observe CONTROL_LOOP_STATE_CHANGE going from runtime to participant
 - Observe that the ControlLoopElements state is UNINITIALISED
 - Observe that the controlloop state is UNINITIALISED


@@ -133,12 +174,15 @@ Test result:
 
 3.10 Control Loop monitoring and reporting
 ==========================================
 
 3.10 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
 Action: Bring up participant
 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
 Action: Bring up participant

+

 Test result:
 Test result:

+

 - Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
 - Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of control loop type definitions sent
 - Observe that PARTICIPANT_STATUS message is sent from participants to runtime in a regular interval
 - Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of control loop type definitions sent

-from all the participants to runtime
+  from all the participants to runtime

 
 This concluded the required smoke tests
 
 
 This concluded the required smoke tests
 

diff --git a/docs/development/devtools/clamp-smoke.rst b/docs/development/devtools/clamp-smoke.rst
index 06ec6db..764c9ff 100644 (file)
--- a/docs/development/devtools/clamp-smoke.rst
+++ b/docs/development/devtools/clamp-smoke.rst
@@ -2,7 +2,7 @@
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 

-.. _policy-development-tools-label:
+.. _policy-clamp-runtime-smoke-label:

 
 CLAMP control loop runtime Smoke Tests
 ######################################
 
 CLAMP control loop runtime Smoke Tests
 ######################################

diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst
index dd33de5..97acac4 100644 (file)
--- a/docs/development/devtools/devtools.rst
+++ b/docs/development/devtools/devtools.rst
@@ -58,7 +58,7 @@ ONAP Policy Framework has dependencies to the ONAP Parent *oparent* module, the
     policy/xacml-pdp \
     policy/distribution \
     policy/gui \
     policy/xacml-pdp \
     policy/distribution \
     policy/gui \

-    policy/engine "
+    policy/clamp "

 
     ##
     ## Help screen and exit condition (i.e. too few arguments)
 
     ##
     ## Help screen and exit condition (i.e. too few arguments)


@@ -152,7 +152,7 @@ Execution of the script above results in the following directory hierarchy in yo
     *  ~/git/onap/policy/docker
     *  ~/git/onap/policy/drools-applications
     *  ~/git/onap/policy/drools-pdp
     *  ~/git/onap/policy/docker
     *  ~/git/onap/policy/drools-applications
     *  ~/git/onap/policy/drools-pdp

-    *  ~/git/onap/policy/engine
+    *  ~/git/onap/policy/clamp

     *  ~/git/onap/policy/apex-pdp
     *  ~/git/onap/policy/xacml-pdp
     *  ~/git/onap/policy/distribution
     *  ~/git/onap/policy/apex-pdp
     *  ~/git/onap/policy/xacml-pdp
     *  ~/git/onap/policy/distribution


@@ -198,10 +198,7 @@ Building ONAP Policy Framework Components
             <module>drools-applications</module>
             <module>distribution</module>
             <module>gui</module>
             <module>drools-applications</module>
             <module>distribution</module>
             <module>gui</module>

-            <!-- The engine repo is being deprecated,
-            and can be ommitted if not working with
-            legacy api and components. -->
-            <module>engine</module>
+            <module>clamp</module>

         </modules>
     </project>
 
         </modules>
     </project>
 


@@ -277,12 +274,12 @@ familiar with the Policy Framework components and test any local changes.
    :maxdepth: 1
 
    policy-gui-controlloop-smoke.rst
    :maxdepth: 1
 
    policy-gui-controlloop-smoke.rst

-
-   policy-participant-smoke.rst
-

    db-migrator-smoke.rst
    db-migrator-smoke.rst

-

    cl-participants-smoke.rst
    cl-participants-smoke.rst

+   clamp-smoke.rst
+   clamp-cl-participant-protocol-smoke.rst
+   policy-participant-smoke.rst
+

 ..
    api-smoke.rst
 
 ..
    api-smoke.rst
 


@@ -301,11 +298,6 @@ familiar with the Policy Framework components and test any local changes.
 ..
    distribution-smoke.rst
 
 ..
    distribution-smoke.rst
 

-..
-   clamp-smoke.rst
-
-..
-   clamp-cl-participant-protocol-smoke.rst

 
 Running the Stability/Performance Tests
 ***************************************
 
 Running the Stability/Performance Tests
 ***************************************

diff --git a/docs/development/devtools/policy-participant-smoke.rst b/docs/development/devtools/policy-participant-smoke.rst
index 113e16c..5838c03 100644 (file)
--- a/docs/development/devtools/policy-participant-smoke.rst
+++ b/docs/development/devtools/policy-participant-smoke.rst
@@ -4,16 +4,20 @@
 
 CLAMP Policy Participant Smoke Tests
 ------------------------------------
 
 CLAMP Policy Participant Smoke Tests
 ------------------------------------

+

 1. Introduction
 ***************
 1. Introduction
 ***************

+

 The Smoke testing of the policy participant is executed in a local CLAMP/Policy environment. The CLAMP-Controlloop interfaces interact with the Policy Framework to perform actions based on the state of the policy participant. The goal of the Smoke tests is the ensure that CLAMP Policy Participant and Policy Framework work together as expected.
 
 2. Setup Guide
 **************
 The Smoke testing of the policy participant is executed in a local CLAMP/Policy environment. The CLAMP-Controlloop interfaces interact with the Policy Framework to perform actions based on the state of the policy participant. The goal of the Smoke tests is the ensure that CLAMP Policy Participant and Policy Framework work together as expected.
 
 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.
 
 2.1 Prerequisites
 =================
 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.
 
 2.1 Prerequisites
 =================

+

 - Java 11
 - Maven 3
 - Git
 - Java 11
 - Maven 3
 - Git


@@ -34,6 +38,7 @@ The following repositories are required for development in this project. These r
 - policy/docker
 - policy/gui
 - policy/api
 - policy/docker
 - policy/gui
 - policy/api

+

 In this setup guide, we will be setting up all the components technically required for a working convenient dev environment.
 
 2.3 Setting up the components
 In this setup guide, we will be setting up all the components technically required for a working convenient dev environment.
 
 2.3 Setting up the components


@@ -73,6 +78,7 @@ This will setup the two databases needed. The database will be exposed locally o
 
 2.3.2 DMAAP Simulator
 ^^^^^^^^^^^^^^^^^^^^^
 
 2.3.2 DMAAP Simulator
 ^^^^^^^^^^^^^^^^^^^^^

+

 For convenience, a dmaap simulator has been provided in the policy/models repository. To start the simulator, you can do the following:
 1. Navigate to /models-sim/policy-models-simulators in the policy/models repository.
 2. Add a configuration file to src/test/resources with the following contents:
 For convenience, a dmaap simulator has been provided in the policy/models repository. To start the simulator, you can do the following:
 1. Navigate to /models-sim/policy-models-simulators in the policy/models repository.
 2. Add a configuration file to src/test/resources with the following contents:


@@ -105,6 +111,7 @@ At this stage the dmaap simulator should be running on your local machine on por
 
 2.3.3 Policy API
 ^^^^^^^^^^^^^^^^
 
 2.3.3 Policy API
 ^^^^^^^^^^^^^^^^

+

 In the policy-api repo, you should find the file "src/main/resources/etc/defaultConfig.json". This file must be altered slightly - as below with the restServerParameters and databaseProviderParameters shown. Note how the database parameters match-up with what you setup in Mariadb:
 
 .. code-block:: json
 In the policy-api repo, you should find the file "src/main/resources/etc/defaultConfig.json". This file must be altered slightly - as below with the restServerParameters and databaseProviderParameters shown. Note how the database parameters match-up with what you setup in Mariadb:
 
 .. code-block:: json


@@ -138,6 +145,7 @@ Next, navigate to the "/main" directory. You can then run the following command
 
 2.3.4 Policy PAP
 ^^^^^^^^^^^^^^^^
 
 2.3.4 Policy PAP
 ^^^^^^^^^^^^^^^^

+

 In the policy-pap repo, you should find the file 'main/src/test/resources/parameters/PapConfigParameters.json'. This file may need to be altered slightly as below:
 
 .. code-block:: json
 In the policy-pap repo, you should find the file 'main/src/test/resources/parameters/PapConfigParameters.json'. This file may need to be altered slightly as below:
 
 .. code-block:: json


@@ -215,6 +223,7 @@ Next, navigate to the "/main" directory. You can then run the following command
 
 2.3.5 Controlloop Runtime
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 2.3.5 Controlloop Runtime
 ^^^^^^^^^^^^^^^^^^^^^^^^^

+

 To start the controlloop runtime we need to go the "runtime-controlloop" directory in the clamp repo. There is a config file that is used, by default, for the controlloop runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the controlloop runtime with:
 
 .. code-block:: bash
 To start the controlloop runtime we need to go the "runtime-controlloop" directory in the clamp repo. There is a config file that is used, by default, for the controlloop runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the controlloop runtime with:
 
 .. code-block:: bash


@@ -223,6 +232,7 @@ To start the controlloop runtime we need to go the "runtime-controlloop" directo
 
 2.3.6 Controlloop Policy Participant
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 2.3.6 Controlloop Policy Participant
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

 To start the policy participant we need to go to the "participant-impl/participant-impl-policy" directory in the clamp repo. There is a config file under "src/main/resources/config/application.yaml". For development in your local environment, we will need to adjust this file slightly:
 
 .. code-block:: yaml
 To start the policy participant we need to go to the "participant-impl/participant-impl-policy" directory in the clamp repo. There is a config file under "src/main/resources/config/application.yaml". For development in your local environment, we will need to adjust this file slightly:
 
 .. code-block:: yaml


@@ -284,6 +294,7 @@ Navigate to the participant-impl/particpant-impl-policy/main directory. We can t
 
 3.1 Testing Outline
 ^^^^^^^^^^^^^^^^^^^
 
 3.1 Testing Outline
 ^^^^^^^^^^^^^^^^^^^

+

 To perform the Smoke testing of the policy-participant we will be verifying the behaviours of the participant when the control loop changes state. The scenarios are:
 
 - UNINITIALISED to PASSIVE: participant creates policies and policyTypes specified in the ToscaServiceTemplate using policy-api
 To perform the Smoke testing of the policy-participant we will be verifying the behaviours of the participant when the control loop changes state. The scenarios are:
 
 - UNINITIALISED to PASSIVE: participant creates policies and policyTypes specified in the ToscaServiceTemplate using policy-api


@@ -296,6 +307,7 @@ To perform the Smoke testing of the policy-participant we will be verifying the
 
 Creation of Controlloop:
 ************************
 
 Creation of Controlloop:
 ************************

+

 A Control Loop is created by commissioning a Tosca template with Control loop definitions and instantiating the Control Loop with the state "UNINITIALISED".
 Using postman, commision a TOSCA template and instantiate using the following template:
 
 A Control Loop is created by commissioning a Tosca template with Control loop definitions and instantiating the Control Loop with the state "UNINITIALISED".
 Using postman, commision a TOSCA template and instantiate using the following template:
 


@@ -309,6 +321,7 @@ To verify this, we check that the Controlloop has been created and is in state U
 
 Creation of policies and policyTypes:
 *************************************
 
 Creation of policies and policyTypes:
 *************************************

+

 The Controlloop STATE is changed from UNINITIALISED to PASSIVE using postman:
 
 .. code-block:: json
 The Controlloop STATE is changed from UNINITIALISED to PASSIVE using postman:
 
 .. code-block:: json


@@ -333,6 +346,7 @@ We can also check that the pm-control policy has been created.
 
 Deployment of policies:
 ***********************
 
 Deployment of policies:
 ***********************

+

 The Controlloop STATE is changed from PASSIVE to RUNNING using postman:
 
 .. code-block:: json
 The Controlloop STATE is changed from PASSIVE to RUNNING using postman:
 
 .. code-block:: json


@@ -353,6 +367,7 @@ This state change will trigger the deployment of the policies specified in the T
 
 Undeployment of policies:
 *************************
 
 Undeployment of policies:
 *************************

+

 The Controlloop STATE is changed from RUNNING to PASSIVE using postman:
 
 .. code-block:: json
 The Controlloop STATE is changed from RUNNING to PASSIVE using postman:
 
 .. code-block:: json


@@ -373,6 +388,7 @@ This state change will trigger the undeployment of the pmcontrol policy which wa
 
 Deletion of policies and policyTypes:
 *************************************
 
 Deletion of policies and policyTypes:
 *************************************

+

 The Controlloop STATE is changed from PASSIVE to UNINITIALISED using postman:
 
 .. code-block:: json
 The Controlloop STATE is changed from PASSIVE to UNINITIALISED using postman:
 
 .. code-block:: json


@@ -392,4 +408,3 @@ This state change will trigger the deletion of the previously created policies a
     .. image:: images/pol-part-controlloop-sirisha-nf.png
 
     .. image:: images/pol-part-controlloop-pmcontrol-nf.png
     .. image:: images/pol-part-controlloop-sirisha-nf.png
 
     .. image:: images/pol-part-controlloop-pmcontrol-nf.png

-