diff options
Diffstat (limited to 'docs/development')
| -rw-r--r-- | docs/development/devtools/acm-participants-smoke.rst (renamed from docs/development/devtools/cl-participants-smoke.rst) | 75 | ||||
| -rw-r--r-- | docs/development/devtools/clamp-cl-participant-protocol-smoke.rst | 124 | ||||
| -rw-r--r-- | docs/development/devtools/clamp-dcae.rst | 24 | ||||
| -rw-r--r-- | docs/development/devtools/clamp-policy.rst | 68 | ||||
| -rw-r--r-- | docs/development/devtools/db-migrator-smoke.rst | 23 | ||||
| -rw-r--r-- | docs/development/devtools/devtools.rst | 2 | ||||
| -rw-r--r-- | docs/development/devtools/json/acm-instantiation.json (renamed from docs/development/devtools/json/cl-instantiation.json) | 18 | ||||
| -rw-r--r-- | docs/development/devtools/policy-cds.rst | 4 | ||||
| -rw-r--r-- | docs/development/devtools/policy-gui-acm-smoke.rst (renamed from docs/development/devtools/policy-gui-controlloop-smoke.rst) | 44 | ||||
| -rw-r--r-- | docs/development/devtools/policy-participant-smoke.rst | 261 | ||||
| -rw-r--r-- | docs/development/devtools/tosca/smoke-test-participants.yaml | 68 |
11 files changed, 339 insertions, 372 deletions
diff --git a/docs/development/devtools/cl-participants-smoke.rst b/docs/development/devtools/acm-participants-smoke.rst index 202f5d75..3c5b6f88 100644 --- a/docs/development/devtools/cl-participants-smoke.rst +++ b/docs/development/devtools/acm-participants-smoke.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-controlloop-participants-smoke-tests: +.. _clamp-acm-participants-smoke-tests: CLAMP participants (kubernetes, http) Smoke Tests ------------------------------------------------- @@ -8,7 +8,7 @@ CLAMP participants (kubernetes, http) Smoke Tests *************** The CLAMP participants (kubernetes and http) are used to interact with the helm client in a kubernetes environment for the deployment of microservices via helm chart as well as to configure the microservices over REST endpoints. Both of these participants are -often used together in the Control loop workflow. +often used together in the Automation Composition Management workflow. This document will serve as a guide to do smoke tests on the different components that are involved when working with the participants and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on these participants. @@ -53,19 +53,19 @@ In this setup guide, we will be setting up all the components technically requir 2.3.1 MariaDB Setup ^^^^^^^^^^^^^^^^^^^ -We will be using Docker to run our mariadb instance. It will have the runtime-controlloop database running in it. +We will be using Docker to run our mariadb instance. It will have the acm-runtime database running in it. -- controlloop: the runtime-controlloop db +- AutomationComposition: the runtime-acm db The easiest way to do this is to perform a small alteration on an SQL script provided by the clamp backend in the file "runtime/extra/sql/bulkload/create-db.sql" .. code-block:: mysql - CREATE DATABASE `controlloop`; - USE `controlloop`; + CREATE DATABASE `clampacm`; + USE `clampacm`; DROP USER 'policy'; CREATE USER 'policy'; - GRANT ALL on controlloop.* to 'policy' identified by 'P01icY' with GRANT OPTION; + GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION; Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh" @@ -73,7 +73,7 @@ Once this has been done, we can run the bash script provided here: "runtime/extr ./start-db.sh -This will setup all the Control Loop runtime database. The database will be exposed locally on port 3306 and will be backed by an anonymous docker volume. +This will setup all the automation composition runtime database. The database will be exposed locally on port 3306 and will be backed by an anonymous docker volume. 2.3.2 DMAAP Simulator ^^^^^^^^^^^^^^^^^^^^^ @@ -109,9 +109,9 @@ For convenience, a dmaap simulator has been provided in the policy/models reposi At this stage the dmaap simulator should be running on your local machine on port 3904. -2.3.3 Controlloop Runtime -^^^^^^^^^^^^^^^^^^^^^^^^^ -To start the controlloop runtime service, we need to execute the following maven command from the "runtime-controlloop" directory in the clamp repo. Control Loop runtime uses the config file "src/main/resources/application.yaml" by default. +2.3.3 Automation composition Runtime +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To start the automation composition runtime service, we need to execute the following maven command from the "runtime-acm" directory in the clamp repo. Automation composition runtime uses the config file "src/main/resources/application.yaml" by default. .. code-block:: bash @@ -129,7 +129,7 @@ The following command can be used to add nginx repository to the helm client. 2.3.5 Kubernetes and http participants ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The participants can be started from the clamp repository by executing the following maven command from the appropriate directories. -The participants will be started and get registered to the Control Loop runtime. +The participants will be started and get registered to the Automation composition runtime. Navigate to the directory "participant/participant-impl/participant-impl-kubernetes/" and start kubernetes participant. @@ -143,16 +143,23 @@ Navigate to the directory "participant/participant-impl/participant-impl-http/" mvn spring-boot:run +For building docker images of runtime-acm and participants: + +.. code-block:: bash + + cd ~/git/onap/policy/clamp/packages/ + mvn clean install -P docker + 3. Running Tests **************** -In this section, we will run through the sequence of steps in Control Loop workflow . The workflow can be triggered via Postman client. +In this section, we will run through the sequence of steps in ACM workflow . The workflow can be triggered via Postman client. 3.1 Commissioning ================= -Commission Control loop TOSCA definitions to Runtime. +Commission Automation composition TOSCA definitions to Runtime. -The Control Loop definitions are commissioned to CL runtime which populates the CL runtime database. +The Automation composition definitions are commissioned to runtime-acm which populates the ACM runtime database. The following sample TOSCA template is commissioned to the runtime endpoint which contains definitions for kubernetes participant that deploys nginx ingress microservice helm chart and a http POST request for http participant. @@ -162,41 +169,41 @@ Commissioning Endpoint: .. code-block:: bash - POST: https://<CL Runtime IP> : <Port> /onap/controlloop/v2/commission + POST: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/commission A successful commissioning gives 200 response in the postman client. -3.2 Create New Instances of Control Loops -========================================= -Once the template is commissioned, we can instantiate Control Loop instances. This will create the instances with default state "UNINITIALISED". +3.2 Create New Instances of Automation composition +================================================== +Once the template is commissioned, we can instantiate automation composition instances. This will create the instances with default state "UNINITIALISED". Instantiation Endpoint: .. code-block:: bash - POST: https://<CL Runtime IP> : <Port> /onap/controlloop/v2/instantiation + POST: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/instantiation Request body: -:download:`Instantiation json <json/cl-instantiation.json>` +:download:`Instantiation json <json/acm-instantiation.json>` 3.3 Change the State of the Instance ==================================== -When the Control loop is updated with state “PASSIVE”, the Kubernetes participant fetches the node template for all control loop elements and deploys the helm chart of each CL 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 in to the cluster. The following sample json input is passed on the request body. -Control Loop Update Endpoint: +Automation Composition Update Endpoint: .. code-block:: bash - PUT: https://<CL Runtime IP> : <Port> /onap/controlloop/v2/instantiation/command + PUT: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/instantiation/command Request body: .. code-block:: bash { "orderedState": "PASSIVE", - "controlLoopIdentifierList": [ + "automationCompositionIdentifierList": [ { "name": "K8SInstance0", "version": "1.0.1" @@ -214,31 +221,31 @@ The following command can be used to verify the pods deployed successfully by ku helm ls -n onap | grep nginx kubectl get po -n onap | grep nginx -The overall state of the control loop should be "PASSIVE" to indicate both the participants has successfully completed the operations. This can be verified by the following rest endpoint. +The overall state of the automation composition should be "PASSIVE" to indicate both the participants has successfully completed the operations. This can be verified by the following rest endpoint. -Verify control loop state: +Verify automation composition state: .. code-block:: bash - GET: https://<CL Runtime IP> : <Port>/onap/controlloop/v2/instantiation + GET: https://<Runtime ACM IP> : <Port>/onap/policy/clamp/acm/v2/instantiation -3.4 Control Loop can be "UNINITIALISED" after deployment -======================================================== +3.4 Automation Compositions can be "UNINITIALISED" after deployment +=================================================================== -By changing the state to "UNINITIALISED", all the helm deployments under the corresponding control loop will be uninstalled from the cluster. -Control Loop Update Endpoint: +By changing the state to "UNINITIALISED", all the helm deployments under the corresponding automation composition will be uninstalled from the cluster. +Automation Composition Update Endpoint: .. code-block:: bash - PUT: https://<CL Runtime IP> : <Port> /onap/controlloop/v2/instantiation/command + PUT: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/instantiation/command Request body: .. code-block:: bash { "orderedState": "UNINITIALISED", - "controlLoopIdentifierList": [ + "automationCompositionIdentifierList": [ { "name": "K8SInstance0", "version": "1.0.1" diff --git a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst index 67005fa3..4ad03984 100644 --- a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst +++ b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst @@ -7,8 +7,8 @@ CLAMP Participant Protocol Smoke Tests 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. +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 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. @@ -32,10 +32,10 @@ Linux user - although the majority of the steps show will be exactly the same in 2.2 Setting up the components ============================= -- Controlloop runtime component docker image is started and running. +- Automation Composition 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 In this setup guide, we will be setting up all the components technically required for a working convenient @@ -47,7 +47,7 @@ example. 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 +- clampacm: the runtime-clampacm db - policyadmin: the policy-api db 3. Running Tests of protocol dialogues @@ -81,107 +81,107 @@ Test result: 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 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 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 going from runtime to participant with acm type definitions and common property values for participant types +- Observe that the acm 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 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 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 acm instances exist in runtime database, return a response for the REST API with error response saying "Cannot decommission acm type definition" +- If no acm instances exist in runtime database, Observe PARTICIPANT_UPDATE going from runtime to participant with definitions as null +- Observe that the acm type definitions and common property values for participant types are removed on ParticipantHandler - Observe PARTICIPANT_UPDATE_ACK going from runtime to participant -3.5 Control Loop Update -======================= +3.5 Automation Composition Update +================================= -Control Loop Update handles creation, change, and deletion of control loops on participants. -Action: Trigger controlloop instantiation from GUI +Automation Composition Update handles creation, change, and deletion of automation compositions on participants. +Action: Trigger acm instantiation from GUI 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_ACK going from participant to runtime +- Observe AUTOMATION_COMPOSITION_UPDATE going from runtime to participant +- Observe that the acm type instances and respective property values for participant types are stored on AutomationCompositionHandler +- Observe that the acm state is UNINITIALISED +- Observe AUTOMATION_COMPOSITION_UPDATE_ACK going from participant to runtime -3.6 Control Loop state change to PASSIVE -======================================== +3.6 Automation Composition 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 +Automation Composition Update handles creation, change, and deletion of automation compositions on participants. +Action: Change state of the acm to PASSIVE 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_ACK going from participant to runtime +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant +- Observe that the AutomationCompositionElements state is PASSIVE +- Observe that the acm state is PASSIVE +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime -3.7 Control Loop state change to RUNNING -======================================== +3.7 Automation Composition 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 +Automation Composition Update handles creation, change, and deletion of automation compositions on participants. +Action: Change state of the acm to RUNNING 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_ACK going from participant to runtime +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant +- Observe that the AutomationCompositionElements state is RUNNING +- Observe that the acm state is RUNNING +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime -3.8 Control Loop state change to PASSIVE -======================================== +3.8 Automation Composition 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 +Automation Composition Update handles creation, change, and deletion of automation compositions on participants. +Action: Change state of the acm to PASSIVE 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_ACK going from participant to runtime +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant +- Observe that the AutomationCompositionElements state is PASSIVE +- Observe that the acm state is PASSIVE +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime -3.9 Control Loop state change to UNINITIALISED -============================================== +3.9 Automation Composition 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 +Automation Composition Update handles creation, change, and deletion of automation compositions on participants. +Action: Change state of the acm to UNINITIALISED 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 that the ControlLoopElements undeploy the instances from respective frameworks -- Observe that the control loop instances are removed from participants -- Observe CONTROL_LOOP_STATE_CHANGE_ACK going from participant to runtime +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE going from runtime to participant +- Observe that the AutomationCompositionElements state is UNINITIALISED +- Observe that the acm state is UNINITIALISED +- Observe that the AutomationCompositionElements undeploy the instances from respective frameworks +- Observe that the automation composition instances are removed from participants +- Observe AUTOMATION_COMPOSITION_STATE_CHANGE_ACK going from participant to runtime -3.10 Control Loop monitoring and reporting -========================================== +3.10 Automation Composition 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 +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 Action: Bring up participant 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 +- Trigger a PARTICIPANT_STATUS_REQ from runtime and observe a PARTICIPANT_STATUS message with tosca definitions of automation composition type definitions sent from all the participants to runtime This concluded the required smoke tests 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/db-migrator-smoke.rst b/docs/development/devtools/db-migrator-smoke.rst index 4aa41e46..54673779 100644 --- a/docs/development/devtools/db-migrator-smoke.rst +++ b/docs/development/devtools/db-migrator-smoke.rst @@ -15,8 +15,10 @@ Check number of files in each release ls 0800/upgrade/*.sql | wc -l = 96 ls 0900/upgrade/*.sql | wc -l = 13 + ls 1000/upgrade/*.sql | wc -l = 9 ls 0800/downgrade/*.sql | wc -l = 96 ls 0900/downgrade/*.sql | wc -l = 13 + ls 1000/downgrade/*.sql | wc -l = 9 Upgrade scripts =============== @@ -25,7 +27,9 @@ Upgrade scripts :number-lines: /opt/app/policy/bin/prepare_upgrade.sh policyadmin - /opt/app/policy/bin/db-migrator -s policyadmin -o upgrade + /opt/app/policy/bin/db-migrator -s policyadmin -o upgrade # upgrade to Jakarta version (latest) + /opt/app/policy/bin/db-migrator -s policyadmin -o upgrade -t 0900 # upgrade to Istanbul + /opt/app/policy/bin/db-migrator -s policyadmin -o upgrade -t 0800 # upgrade to Honolulu .. note:: You can also run db-migrator upgrade with the -t and -f options @@ -37,7 +41,9 @@ Downgrade scripts :number-lines: /opt/app/policy/bin/prepare_downgrade.sh policyadmin - /opt/app/policy/bin/db-migrator -s policyadmin -o downgrade -f 0900 -t 0800 + /opt/app/policy/bin/db-migrator -s policyadmin -o downgrade -t 0900 # downgrade to Istanbul + /opt/app/policy/bin/db-migrator -s policyadmin -o downgrade -t 0800 # downgrade to Honolulu + /opt/app/policy/bin/db-migrator -s policyadmin -o downgrade -t 0 # delete all tables Db migrator initialization script ================================= @@ -56,18 +62,18 @@ Every time you modify db_migrator_policy_init.sh you will have to undeploy, make :header-rows: 0 * - Number of files run - - 109 + - 118 * - Tables in policyadmin - - 75 + - 70 * - Records Added - - 109 + - 118 * - schema_version - - 0900 + - 1000 2. Downgrade to Honolulu (0800) ******************************* -Modify db_migrator_policy_init.sh - remove any lines referencing upgrade and add the 2 lines under "Downgrade scripts" +Modify db_migrator_policy_init.sh - remove any lines referencing upgrade and add the 2 lines under "Downgrade scripts" tagged as Honolulu Make/Redeploy to run downgrade. @@ -410,4 +416,7 @@ Check the pdp table to ensure the LASTUPDATE column has been added and the value .. note:: The number of records added may vary depnding 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. + End of Document diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst index a564d5d9..6ea36899 100644 --- a/docs/development/devtools/devtools.rst +++ b/docs/development/devtools/devtools.rst @@ -273,7 +273,7 @@ familiar with the Policy Framework components and test any local changes. .. toctree:: :maxdepth: 1 - policy-gui-controlloop-smoke.rst + policy-gui-acm-smoke.rst db-migrator-smoke.rst cl-participants-smoke.rst clamp-smoke.rst diff --git a/docs/development/devtools/json/cl-instantiation.json b/docs/development/devtools/json/acm-instantiation.json index 66197860..9977cf02 100644 --- a/docs/development/devtools/json/cl-instantiation.json +++ b/docs/development/devtools/json/acm-instantiation.json @@ -1,20 +1,20 @@ { - "controlLoopList": [ + "automationCompositionList ": [ { "name": "K8SInstance0", "version": "1.0.1", "definition": { - "name": "org.onap.domain.sample.GenericK8s_ControlLoopDefinition", + "name": "org.onap.domain.sample.GenericK8s_AutomationCompositionDefinition", "version": "1.2.3" }, "state": "UNINITIALISED", "orderedState": "UNINITIALISED", - "description": "K8s control loop instance 0", + "description": "K8s automation composition instance 0", "elements": { "709c62b3-8918-41b9-a747-d21eb79c6c21": { "id": "709c62b3-8918-41b9-a747-d21eb79c6c21", "definition": { - "name": "org.onap.domain.database.Local_K8SMicroserviceControlLoopElement", + "name": "org.onap.policy.clamp.Local_K8SMicroserviceAutomationCompositionElement", "version": "1.2.3" }, "participantId": { @@ -22,17 +22,17 @@ "version": "1.0.0" }, "participantType": { - "name": "org.onap.k8s.controlloop.K8SControlLoopParticipant", + "name": "org.onap.policy.clamp.acm.KubernetesParticipant", "version": "2.3.4" }, "state": "UNINITIALISED", "orderedState": "UNINITIALISED", - "description": "K8s Control Loop Element for the nginx-ingress microservice" + "description": "K8s Automation composition Element for the nginx-ingress microservice" }, "709c62b3-8918-41b9-a747-d21eb79c6c22": { "id": "709c62b3-8918-41b9-a747-d21eb79c6c22", "definition": { - "name": "org.onap.domain.database.Http_MicroserviceControlLoopElement", + "name": "org.onap.policy.clamp.Http_AutomationCompositionElement", "version": "1.2.3" }, "participantId": { @@ -40,12 +40,12 @@ "version": "1.0.0" }, "participantType": { - "name": "org.onap.k8s.controlloop.HttpControlLoopParticipant", + "name": "org.onap.policy.clamp.acm.HttpParticipant", "version": "2.3.4" }, "state": "UNINITIALISED", "orderedState": "UNINITIALISED", - "description": "Http Control Loop Element" + "description": "Http Automation composition Element" } } } 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. diff --git a/docs/development/devtools/policy-gui-controlloop-smoke.rst b/docs/development/devtools/policy-gui-acm-smoke.rst index aa319651..8070204c 100644 --- a/docs/development/devtools/policy-gui-controlloop-smoke.rst +++ b/docs/development/devtools/policy-gui-acm-smoke.rst @@ -1,20 +1,20 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. _clamp-gui-controlloop-smoke-tests: +.. _clamp-gui-acm-smoke-tests: CLAMP GUI Smoke Tests --------------------------- 1. Introduction *************** -The CLAMP GUI for Control Loops is designed to provide a user the ability to interact -with the Control Loop Runtime to perform several actions. +The CLAMP GUI for Automation Compositions is designed to provide a user the ability to interact +with the Automation Composition Runtime to perform several actions. - Commission new Tosca Service Templates. - Editing Common Properties. - Decommission existing Tosca Service Templates. -- Create new instances of Control Loops. -- Change the state of the Control Loops. -- Delete Control Loops. +- Create new instances of Automation Compositions. +- Change the state of the Automation Compositions. +- Delete Automation Compositions. This document will serve as a guide to do smoke tests on the different components that are involved when working with the GUI and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on the GUI. @@ -56,7 +56,7 @@ In this setup guide, we will be setting up all the components technically requir ^^^^^^^^^^^^^^^^^^^ We will be using Docker to run our mariadb instance. It will have a total of three databases running in it. -- controlloop: the runtime-controlloop db +- acm: the clampacm db - cldsdb4: the clamp backend db - policyadmin: the policy-api db @@ -69,16 +69,16 @@ The easiest way to do this is to perform a small alteration on an SQL script pro DROP USER 'clds'; CREATE USER 'clds'; GRANT ALL on cldsdb4.* to 'clds' identified by 'sidnnd83K' with GRANT OPTION; - CREATE DATABASE `controlloop`; - USE `controlloop`; + CREATE DATABASE `clampacm`; + USE `clampacm`; DROP USER 'policy'; CREATE USER 'policy'; - GRANT ALL on controlloop.* to 'policy' identified by 'P01icY' with GRANT OPTION; + GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION; CREATE DATABASE `policyadmin`; USE `policyadmin`; DROP USER 'policy_user'; CREATE USER 'policy_user'; - GRANT ALL on controlloop.* to 'policy_user' identified by 'policy_user' with GRANT OPTION; + GRANT ALL on clampacm.* to 'policy_user' identified by 'policy_user' with GRANT OPTION; FLUSH PRIVILEGES; Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh" @@ -157,7 +157,7 @@ Next, navigate to the "/main" directory. You can then run the following command 2.3.6 Clamp Backend ^^^^^^^^^^^^^^^^^^^ -The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For controlloop development purposes, we only need to connect with the controlloop runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh" +The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For acm development purposes, we only need to connect with the acm runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh" .. code-block:: bash @@ -169,19 +169,19 @@ Once the emulator is running, we can then run the clamp backend. Before doing th ./start-backend.sh -Once the clamp backend is running, we can start the controlloop runtime. +Once the clamp backend is running, we can start the acm runtime. -2.3.7 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: +2.3.7 Automation Composition Runtime +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To start the acm runtime we need to go the "runtime-acm" directory in the clamp repo. There is a config file that is used, by default, for the acm 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 acm runtime with: .. code-block:: bash mvn spring-boot:run -2.3.8 Controlloop GUI -^^^^^^^^^^^^^^^^^^^^^ -At this point, all of the components required to test out the controlloop 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. +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. 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: @@ -224,7 +224,7 @@ This confirms that commissioning has been complete. 3.2 Edit Common Properties ========================== -At this stage we can edit the common properties. These properties will be common to all instances of the control loop definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below. +At this stage we can edit the common properties. These properties will be common to all instances of the automation composition definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below. .. image:: images/gui/CommonPropertiesModal.png @@ -232,8 +232,8 @@ The arrows to the left of the modal can be used to expand and contract the eleme .. image:: images/gui/ViewEditedCommonProperties.png -3.3 Create New Instances of Control Loops -========================================= +3.3 Create New Instances of Automation Compositions +=================================================== Once the template is commissioned, we can start to create instances. In the dropdown, click on "Instantiation Management". In the modal, you will see an empty table, as shown. .. image:: images/gui/ManageInstancesModal.png diff --git a/docs/development/devtools/policy-participant-smoke.rst b/docs/development/devtools/policy-participant-smoke.rst index 5838c034..bf236351 100644 --- a/docs/development/devtools/policy-participant-smoke.rst +++ b/docs/development/devtools/policy-participant-smoke.rst @@ -8,7 +8,7 @@ CLAMP Policy Participant Smoke Tests 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. +The Smoke testing of the policy participant is executed in a local CLAMP/Policy environment. The CLAMP-ACM 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 ************** @@ -49,23 +49,23 @@ In this setup guide, we will be setting up all the components technically requir 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 +- clampacm: the runtime-clampacm db - policyadmin: the policy-api db The easiest way to do this is to perform a small alteration on an SQL script provided by the clamp backend in the file "runtime/extra/sql/bulkload/create-db.sql" .. code-block:: mysql - CREATE DATABASE `controlloop`; - USE `controlloop`; + CREATE DATABASE `clampacm`; + USE `clampacm`; DROP USER 'policy'; CREATE USER 'policy'; - GRANT ALL on controlloop.* to 'policy' identified by 'P01icY' with GRANT OPTION; + GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION; CREATE DATABASE `policyadmin`; USE `policyadmin`; DROP USER 'policy_user'; CREATE USER 'policy_user'; - GRANT ALL on controlloop.* to 'policy_user' identified by 'policy_user' with GRANT OPTION; + GRANT ALL on clampacm.* to 'policy_user' identified by 'policy_user' with GRANT OPTION; FLUSH PRIVILEGES; Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh" @@ -114,28 +114,59 @@ At this stage the dmaap simulator should be running on your local machine on por 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 +.. code-block:: yaml - { - "restServerParameters": { - "host": "0.0.0.0", - "port": 6970, - "userName": "healthcheck", - "password": "zb!XztG34", - "prometheus": true, - "https": false, - "aaf": false - }, - "databaseProviderParameters": { - "name": "PolicyProviderParameterGroup", - "implementation": "org.onap.policy.models.provider.impl.DatabasePolicyModelsProviderImpl", - "databaseDriver": "org.mariadb.jdbc.Driver", - "databaseUrl": "jdbc:mariadb://mariadb:3306/policyadmin", - "databaseUser": "policy_user", - "databasePassword": "policy_user", - "persistenceUnit": "PolicyMariaDb" - }, - } + server: + port: 6969 + spring: + security.user: + name: policyadmin + password: zb!XztG34 + mvc.converters.preferred-json-mapper: gson + datasource: + url: jdbc:mariadb://mariadb:3306/policyadmin + driverClassName: org.mariadb.jdbc.Driver + username: policy_user + password: policy_user + jpa: + properties: + hibernate: + dialect: org.hibernate.dialect.MariaDB103Dialect + hibernate: + ddl-auto: none + naming: + physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl + implicit-strategy: org.onap.policy.common.spring.utils.CustomImplicitNamingStrategy + policy-api: + name: ApiGroup + aaf: false + database: + name: PolicyProviderParameterGroup + implementation: org.onap.policy.models.provider.impl.DatabasePolicyModelsProviderImpl + driver: org.mariadb.jdbc.Driver + url: jdbc:mariadb://mariadb:3306/policyadmin + user: policy_user + password: policy_user + persistenceUnit: PolicyDb + policy-preload: + policyTypes: + - policytypes/onap.policies.monitoring.tcagen2.yaml + - policytypes/onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server.yaml + - policytypes/onap.policies.monitoring.dcae-restconfcollector.yaml + - policytypes/onap.policies.monitoring.dcae-pm-subscription-handler.yaml + - policytypes/onap.policies.monitoring.dcae-pm-mapper.yaml + - policytypes/onap.policies.Optimization.yaml + - policytypes/onap.policies.optimization.Resource.yaml + - policytypes/onap.policies.controlloop.operational.common.Drools.yaml + policies: + - policies/sdnc.policy.naming.input.tosca.yaml + management: + endpoints: + web: + base-path: / + exposure: + include: health,metrics,prometheus + path-mapping.prometheus: metrics Next, navigate to the "/main" directory. You can then run the following command to start the policy api: @@ -148,72 +179,38 @@ Next, navigate to the "/main" directory. You can then run the following command 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 +.. code-block:: yaml - { - "name": "PapGroup", - "restServerParameters": { - "host": "0.0.0.0", - "port": 6968, - "userName": "healthcheck", - "password": "zb!XztG34", - "https": false - }, - "pdpParameters": { - "heartBeatMs": 60000, - "updateParameters": { - "maxRetryCount": 1, - "maxWaitMs": 30000 - }, - "stateChangeParameters": { - "maxRetryCount": 1, - "maxWaitMs": 30000 - } - }, - "databaseProviderParameters": { - "name": "PolicyProviderParameterGroup", - "implementation": "org.onap.policy.models.provider.impl.DatabasePolicyModelsProviderImpl", - "databaseDriver": "org.mariadb.jdbc.Driver", - "databaseUrl": "jdbc:mariadb://localhost:3306/policyadmin", - "databaseUser": "policy_user", - "databasePassword": "policy_user", - "persistenceUnit": "PolicyMariaDb" - }, - "topicParameterGroup": { - "topicSources" : [{ - "topic" : "POLICY-PDP-PAP", - "servers" : [ "localhost:3904" ], - "topicCommInfrastructure" : "dmaap" - }], - "topicSinks" : [{ - "topic" : "POLICY-PDP-PAP", - "servers" : [ "localhost:3904" ], - "topicCommInfrastructure" : "dmaap" - },{ - "topic" : "POLICY-NOTIFICATION", - "servers" : [ "localhost:3904" ], - "topicCommInfrastructure" : "dmaap" - }] - }, - "healthCheckRestClientParameters":[{ - "clientName": "api", - "hostname": "policy-api", - "port": 6968, - "userName": "healthcheck", - "password": "zb!XztG34", - "useHttps": false, - "basePath": "policy/api/v1/healthcheck" - }, - { - "clientName": "distribution", - "hostname": "policy-distribution", - "port": 6970, - "userName": "healthcheck", - "password": "zb!XztG34", - "useHttps": false, - "basePath": "healthcheck" - }] - } + spring: + security: + user: + name: policyadmin + password: zb!XztG34 + http: + converters: + preferred-json-mapper: gson + datasource: + url: jdbc:mariadb://mariadb:3306/policyadmin + driverClassName: org.mariadb.jdbc.Driver + username: policy_user + password: policy_user + jpa: + properties: + hibernate: + dialect: org.hibernate.dialect.MySQL5InnoDBDialect + hibernate: + ddl-auto: none + naming: + physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl + implicit-strategy: org.onap.policy.pap.main.CustomImplicitNamingStrategy + server: + port: 6969 + pap: + name: PapGroup + pdpParameters: + heartBeatMs: 120000 + updateParameters: + maxRetryCount: 1 Next, navigate to the "/main" directory. You can then run the following command to start the policy pap @@ -221,16 +218,16 @@ Next, navigate to the "/main" directory. You can then run the following command mvn -q -e clean compile exec:java -Dexec.mainClass="org.onap.policy.pap.main.startstop.Main" -Dexec.args="-c /src/test/resources/parameters/PapConfigParameters.json" -2.3.5 Controlloop Runtime +2.3.5 ACM 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: +To start the clampacm runtime we need to go the "runtime-clampacm" directory in the clamp repo. There is a config file that is used, by default, for the clampacm 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 clampacm runtime with: .. code-block:: bash mvn spring-boot:run -2.3.6 Controlloop Policy Participant +2.3.6 ACM 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: @@ -266,7 +263,7 @@ To start the policy participant we need to go to the "participant-impl/participa name: org.onap.PM_Policy version: 1.0.0 participantType: - name: org.onap.policy.controlloop.PolicyControlLoopParticipant + name: org.onap.policy.clampacm.PolicyControlLoopParticipant version: 2.3.1 clampControlLoopTopics: topicSources: @@ -297,32 +294,32 @@ Navigate to the participant-impl/particpant-impl-policy/main directory. We can t 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 -- PASSIVE to RUNNING: participant deploys created policies specified in the ToscaServiceTemplate -- RUNNING to PASSIVE: participant undeploys policies which have been deployed -- PASSIVE to UNINITIALISED: participant deletes policies and policyTypes which has been created +- UNINITIALISED to PASSIVE: participant creates policies and policyTypes specified in the ToscaServiceTemplate using policy-api and deploys the policies using pap. +- PASSIVE to RUNNING: participant changes state to RUNNING. No operation performed. +- RUNNING to PASSIVE: participant changes state to PASSIVE. No operation performed. +- PASSIVE to UNINITIALISED: participant undeploys deployed policies and deletes policies and policyTypes which have been created. 3.2 Testing Steps ^^^^^^^^^^^^^^^^^ -Creation of Controlloop: +Creation of ACM: ************************ -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 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>` -:download:`Instantiate Controlloop <tosca/instantiation_pptnt_smoke.json>` +:download:`Instantiate ACM <tosca/instantiation_pptnt_smoke.json>` -To verify this, we check that the Controlloop has been created and is in state UNINITIALISED. +To verify this, we check that the ACM has been created and is in state UNINITIALISED. - .. image:: images/pol-part-controlloop-creation-ver.png + .. image:: images/pol-part-clampacm-creation-ver.png Creation of policies and policyTypes: ************************************* -The Controlloop STATE is changed from UNINITIALISED to PASSIVE using postman: +The ACM STATE is changed from UNINITIALISED to PASSIVE using postman: .. code-block:: json @@ -336,44 +333,32 @@ The Controlloop STATE is changed from UNINITIALISED to PASSIVE using postman: ] } -This state change will trigger the creation of policies and policyTypes using the policy-api. To verify this we will check, using policy-api endpoints, that the "Sirisha" policyType, which is specified in the service template, has been created. +This state change will trigger the creation of policies and policyTypes using the policy-api. To verify this we will check, using policy-api endpoints, that the "Test Policy" policyType, which is specified in the service template, has been created. - .. image:: images/pol-part-controlloop-sirisha-ver.png + .. image:: images/pol-part-clampacm-test-policy-ver.png We can also check that the pm-control policy has been created. - .. image:: images/pol-part-controlloop-pmcontrol-ver.png + .. image:: images/pol-part-clampacm-pmcontrol-ver.png Deployment of policies: *********************** -The Controlloop STATE is changed from PASSIVE to RUNNING using postman: - -.. code-block:: json - - { - "orderedState": "RUNNING", - "controlLoopIdentifierList": [ - { - "name": "PMSHInstance0", - "version": "1.0.1" - } - ] - } +The ACM STATE is changed from UNINITIALISED to PASSIVE using postman: This state change will trigger the deployment of the policies specified in the ToscaServiceTemplate. To verify this, we will check that the apex pmcontrol policy has been deployed to the defaultGroup. We check this using pap: - .. image:: images/pol-part-controlloop-pmcontrol-deploy-ver.png + .. image:: images/pol-part-clampacm-pmcontrol-deploy-ver.png Undeployment of policies: ************************* -The Controlloop STATE is changed from RUNNING to PASSIVE using postman: +The ACM STATE is changed from PASSIVE to UNINITIALISED using postman: .. code-block:: json { - "orderedState": "PASSIVE", + "orderedState": "UNINITIALISED", "controlLoopIdentifierList": [ { "name": "PMSHInstance0", @@ -382,29 +367,17 @@ The Controlloop STATE is changed from RUNNING to PASSIVE using postman: ] } -This state change will trigger the undeployment of the pmcontrol policy which was deployed previously. To verifiy this we do a PdpGroup Query as before and check that the pmcontrol policy has been undeployed and removed from the defaultGroup: +This state change will trigger the undeployment of the pmcontrol policy which was deployed previously. To verify this we do a PdpGroup Query as before and check that the pmcontrol policy has been undeployed and removed from the defaultGroup: - .. image:: images/pol-part-controlloop-pmcontrol-undep-ver.png + .. image:: images/pol-part-clampacm-pmcontrol-undep-ver.png Deletion of policies and policyTypes: ************************************* -The Controlloop STATE is changed from PASSIVE to UNINITIALISED using postman: - -.. code-block:: json - - { - "orderedState": "UNINITIALISED", - "controlLoopIdentifierList": [ - { - "name": "PMSHInstance0", - "version": "1.0.1" - } - ] - } +The ACM STATE is changed from PASSIVE to UNINITIALISED using postman: -This state change will trigger the deletion of the previously created policies and policyTypes. To verify this, as before, we can check that the Sirisha policyType is not found this time and likewise for the pmcontrol policy: +This state change will trigger the deletion of the previously created policies and policyTypes. To verify this, as before, we can check that the Test Policy policyType is not found this time and likewise for the pmcontrol policy: - .. image:: images/pol-part-controlloop-sirisha-nf.png + .. image:: images/pol-part-clampacm-test-policy-nf.png - .. image:: images/pol-part-controlloop-pmcontrol-nf.png + .. image:: images/pol-part-clampacm-pmcontrol-nf.png diff --git a/docs/development/devtools/tosca/smoke-test-participants.yaml b/docs/development/devtools/tosca/smoke-test-participants.yaml index a10e05ec..7823a773 100644 --- a/docs/development/devtools/tosca/smoke-test-participants.yaml +++ b/docs/development/devtools/tosca/smoke-test-participants.yaml @@ -9,7 +9,7 @@ data_types: version: type: string required: true - org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.RestRequest: + org.onap.datatypes.policy.clamp.acm.httpAutomationCompositionElement.RestRequest: version: 1.0.0 derived_from: tosca.datatypes.Root properties: @@ -38,7 +38,7 @@ data_types: constraints: - in_range: [100, 599] description: THe expected HTTP status code for the REST request - org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.ConfigurationEntity: + org.onap.datatypes.policy.clamp.acm.httpAutomationCompositionElement.ConfigurationEntity: version: 1.0.0 derived_from: tosca.datatypes.Root properties: @@ -46,22 +46,22 @@ data_types: type: onap.datatypes.ToscaConceptIdentifier typeVersion: 1.0.0 required: true - description: The name and version of a Configuration Entity to be handled by the HTTP Control Loop Element + description: The name and version of a Configuration Entity to be handled by the HTTP Automation Composition Element restSequence: type: list entry_schema: - type: org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.RestRequest + type: org.onap.datatypes.policy.clamp.acm.httpAutomationCompositionElement.RestRequest typeVersion: 1.0.0 description: A sequence of REST commands to send to the REST endpoint 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 required: false - org.onap.policy.clamp.controlloop.ControlLoopElement: + org.onap.policy.clamp.acm.AutomationCompositionElement: version: 1.0.1 derived_from: tosca.nodetypes.Root properties: @@ -76,7 +76,7 @@ node_types: 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 @@ -84,9 +84,9 @@ node_types: - 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 ACM 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 @@ -124,7 +124,7 @@ node_types: 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: @@ -136,9 +136,9 @@ node_types: required: true entry_schema: type: onap.datatypes.ToscaConceptIdentifier - org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement: + 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 @@ -156,9 +156,9 @@ node_types: values: type: string required: true - org.onap.policy.clamp.controlloop.HttpControlLoopElement: + org.onap.policy.clamp.acm.HttpAutomationCompositionElement: version: 1.0.1 - derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement + derived_from: org.onap.policy.clamp.acm.AutomationCompositionElement properties: baseUrl: type: string @@ -174,31 +174,31 @@ node_types: type: map required: true entry_schema: - type: org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.ConfigurationEntity + type: org.onap.datatypes.policy.clamp.acm.httpAutomationCompositionElement.ConfigurationEntity typeVersion: 1.0.0 - description: The connfiguration entities the Control Loop Element is managing and their associated REST requests + description: The connfiguration entities the Automation Composition Element is managing and their associated REST requests topology_template: node_templates: - org.onap.k8s.controlloop.K8SControlLoopParticipant: + org.onap.policy.clamp.acm.KubernetesParticipant: 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.Local_K8SMicroserviceControlLoopElement: + org.onap.policy.clamp.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.policy.clamp.acm.KubernetesParticipant version: 2.3.4 chart: chartId: @@ -206,26 +206,26 @@ topology_template: version: 0.11.0 releaseName: nginxapp namespace: onap - org.onap.controlloop.HttpControlLoopParticipant: + org.onap.policy.clamp.acm.HttpParticipant: 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 Http requests properties: provider: ONAP - org.onap.domain.database.Http_MicroserviceControlLoopElement: + org.onap.policy.clamp.Http_AutomationCompositionElement: version: 1.2.3 - type: org.onap.policy.clamp.controlloop.HttpControlLoopElement + type: org.onap.policy.clamp.acm.HttpAutomationCompositionElement type_version: 1.0.1 - description: Control loop element for the http requests of PMSH microservice + description: Automation composition element for the http requests of PMSH microservice properties: provider: ONAP participant_id: name: HttpParticipant0 version: 1.0.0 participantType: - name: org.onap.k8s.controlloop.HttpControlLoopParticipant + name: org.onap.policy.clamp.acm.HttpParticipant version: 2.3.4 uninitializedToPassiveTimeout: 180 startPhase: 1 @@ -246,15 +246,15 @@ topology_template: expectedResponse: 200 - 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 compostion for smoke testing participants properties: provider: ONAP elements: - - name: org.onap.domain.database.Local_K8SMicroserviceControlLoopElement + - name: org.onap.policy.clamp.Local_K8SMicroserviceAutomationCompositionElement version: 1.2.3 - - name: org.onap.domain.database.Http_MicroserviceControlLoopElement + - name: org.onap.policy.clamp.Http_AutomationCompositionElement version: 1.2.3 |