diff options
Diffstat (limited to 'docs/development/devtools')
27 files changed, 62 insertions, 61 deletions
diff --git a/docs/development/devtools/acm-participants-smoke.rst b/docs/development/devtools/acm-participants-smoke.rst index 3c5b6f88..5e54d905 100644 --- a/docs/development/devtools/acm-participants-smoke.rst +++ b/docs/development/devtools/acm-participants-smoke.rst @@ -171,7 +171,7 @@ Commissioning Endpoint: POST: https://<Runtime ACM IP> : <Port> /onap/policy/clamp/acm/v2/commission -A successful commissioning gives 200 response in the postman client. +A successful commissioning gives 200 responses in the postman client. 3.2 Create New Instances of Automation composition @@ -190,7 +190,7 @@ Request body: 3.3 Change the State of the Instance ==================================== -When the automation composition is updated with state “PASSIVE”, the Kubernetes participant fetches the node template for all automation composition elements and deploys the helm chart of each AC element in to the cluster. The following sample json input is passed on the request body. +When the automation composition is updated with state “PASSIVE”, the Kubernetes participant fetches the node template for all automation composition elements and deploys the helm chart of each AC element into the cluster. The following sample json input is passed on the request body. Automation Composition Update Endpoint: diff --git a/docs/development/devtools/apex-s3p.rst b/docs/development/devtools/apex-s3p.rst index 04f52acd..a4759f5c 100644 --- a/docs/development/devtools/apex-s3p.rst +++ b/docs/development/devtools/apex-s3p.rst @@ -30,8 +30,8 @@ Setup Details testsuites/performance/performance-benchmark-test/src/main/resources/apexPdpPerformanceTestPlan.jmx .. Note:: - Policy executions are validated in a more strict fashion during the tests. - There are test cases where upto 80 events are expected on the DMaaP topic. + Policy executions are validated in a stricter fashion during the tests. + There are test cases where up to 80 events are expected on the DMaaP topic. DMaaP simulator is used to keep it simple and avoid any message pickup timing related issues. Stability Test of APEX-PDP @@ -90,7 +90,7 @@ The following steps can be used to configure the parameters of test plan. - **HTTP Authorization Manager** - used to store user/password authentication details. - **HTTP Header Manager** - used to store headers which will be used for making HTTP requests. -- **User Defined Variables** - used to store following user defined parameters. +- **User Defined Variables** - used to store following user defined parameters. =================== =============================================================================== **Name** **Description** @@ -205,5 +205,5 @@ Test results are shown as below. Summary +++++++ -Multiple policies were executed in a multi threaded fashion for both stability and performance tests. +Multiple policies were executed in a multi-threaded fashion for both stability and performance tests. Both tests ran smoothly without any issues. diff --git a/docs/development/devtools/apex-smoke.rst b/docs/development/devtools/apex-smoke.rst index ba30e510..3ad44fdd 100644 --- a/docs/development/devtools/apex-smoke.rst +++ b/docs/development/devtools/apex-smoke.rst @@ -47,8 +47,8 @@ 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. -Download & execute the steps in postman collection for creating the entities along with it's dependencies. -The steps needs to be performed sequentially one after another. And no input is required from user. +Download & execute the steps in postman collection for creating the entities along with its dependencies. +The steps need to be performed sequentially one after another. And no input is required from user. :download:`Create VNF & PNF in AAI <postman/create-vnf-pnf-aai.postman_collection.json>` @@ -91,7 +91,7 @@ List of steps covered in the postman collection: - Delete both VNF & PNF policies at the end. Download & execute the steps in postman collection. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. :download:`Apex-PDP VNF & PNF Testing <postman/apex-pdp-vnf-pnf-testing.postman_collection.json>` diff --git a/docs/development/devtools/api-s3p.rst b/docs/development/devtools/api-s3p.rst index ed57cf15..6a815983 100644 --- a/docs/development/devtools/api-s3p.rst +++ b/docs/development/devtools/api-s3p.rst @@ -19,7 +19,7 @@ Introduction The 72 hour stability test of policy API has the goal of verifying the stability of running policy design API REST service by ingesting a steady flow of transactions in a multi-threaded fashion to -simulate multiple clients' behaviors. +simulate multiple clients' behaviours. All the transaction flows are initiated from a test client server running JMeter for the duration of 72 hours. Setup Details @@ -42,7 +42,7 @@ Test Plan The 72+ hours stability test will be running the following steps sequentially in multi-threaded loops. Thread number is set to 5 to simulate 5 API clients' -behaviors (they can be calling the same policy CRUD API simultaneously). +behaviours (they can be calling the same policy CRUD API simultaneously). Each thread creates a different version of the policy types and policies to not interfere with one another while operating simultaneously. The point version of each entity is set to the running thread number. @@ -66,7 +66,7 @@ of each entity is set to the running thread number. - Get All Policy Types - Get All Versions of the new Monitoring Policy Type - Get Version 6.0.# of the new Monitoring Policy Type -- Get Version 6.0.# of the new Optimzation Policy Type +- Get Version 6.0.# of the new Optimization Policy Type - Get Version 6.0.# of the new Guard Policy Type - Get Version 6.0.# of the new Native APEX Policy Type - Get Version 6.0.# of the new Native Drools Policy Type @@ -80,7 +80,7 @@ of each entity is set to the running thread number. - Create Native Drools Policy Ver 6.0.# w/Native Drools Policy Type Ver 6.0.# - Create Native XACML Policy Ver 6.0.# w/Native XACML Policy Type Ver 6.0.# - Get Version 6.0.# of the new Monitoring Policy -- Get Version 6.0.# of the new Optimzation Policy +- Get Version 6.0.# of the new Optimization Policy - Get Version 6.0.# of the new Guard Policy - Get Version 6.0.# of the new Native APEX Policy - Get Version 6.0.# of the new Native Drools Policy @@ -88,7 +88,7 @@ of each entity is set to the running thread number. - Get the Latest Version of the new Monitoring Policy - Delete Version 6.0.# of the new Monitoring Policy - Delete Version 7.0.# of the new Monitoring Policy -- Delete Version 6.0.# of the new Optimzation Policy +- Delete Version 6.0.# of the new OptimizationPolicy - Delete Version 6.0.# of the new Guard Policy - Delete Version 6.0.# of the new Native APEX Policy - Delete Version 6.0.# of the new Native Drools Policy @@ -160,7 +160,7 @@ Setup Details The performance test was performed on a default ONAP OOM installation in the Intel Wind River Lab environment. JMeter was installed on a separate VM to inject the traffic defined in the -`API performace script +`API performance script <https://git.onap.org/policy/api/tree/testsuites/performance/src/main/resources/testplans/policy_api_performance.jmx>`_ with the following command: @@ -174,7 +174,7 @@ Test Plan --------- Performance test plan is the same as stability test plan above. -Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviors at the same time) whereas reducing the test time down to 2.5 hours. +Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviours at the same time) whereas reducing the test time down to 2.5 hours. Run Test -------- diff --git a/docs/development/devtools/api-smoke.rst b/docs/development/devtools/api-smoke.rst index 638546bd..8230f33b 100644 --- a/docs/development/devtools/api-smoke.rst +++ b/docs/development/devtools/api-smoke.rst @@ -40,7 +40,7 @@ The test set is focused on the following use cases: Execute policy-api testing -------------------------- Download & execute the steps in postman collection for verifying policy-api component. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. `Policy Framework Lifecycle API <https://github.com/onap/policy-api/blob/master/postman/lifecycle-api-collection.json>`_ diff --git a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst index 4ad03984..09ab453f 100644 --- a/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst +++ b/docs/development/devtools/clamp-cl-participant-protocol-smoke.rst @@ -9,7 +9,7 @@ CLAMP Participant Protocol Smoke Tests The CLAMP Automation Composition Participant protocol is an asynchronous protocol that is used by the CLAMP runtime to coordinate life cycle management of Automation Composition instances. -This document will serve as a guide to do smoke tests on the different usecases that are involved when +This document will serve as a guide to do smoke tests on the different use cases that are involved when working with the Participant protocol and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on the participants. @@ -17,7 +17,7 @@ It will also show a developer how to set up their environment for carrying out s ************** This section will show the developer how to set up their environment to start testing participants with some -instructions on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a +instructions on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. 2.1 Prerequisites @@ -39,7 +39,7 @@ Linux user - although the majority of the steps show will be exactly the same in - policy-api for communication between policy participant and policy-framework In this setup guide, we will be setting up all the components technically required for a working convenient -dev environment. We will not be setting up all of the participants - we will setup only the policy participant as an +dev environment. We will not be setting up all the participants - we will setup only the policy participant as an example. 2.2.1 MariaDB Setup @@ -81,7 +81,7 @@ Test result: 3.3 Participant Priming ======================= -When a automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants +When an automation composition is primed, the portion of the Automation Composition Type Definition and Common Property values for the participants of each participant type mentioned in the Automation Composition Definition are sent to the participants. Action: Invoke a REST API to prime acm type definitions and set values of common properties @@ -94,7 +94,7 @@ Test result: 3.4 Participant DePriming ========================= -When a automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants +When an automation composition is de-primed, the portion of the Automation Composition Type Definition and Common Property values for the participants of each participant type mentioned in the Automation Composition Definition are deleted on participants. Action: Invoke a REST API to deprime acm type definitions diff --git a/docs/development/devtools/clamp-dcae.rst b/docs/development/devtools/clamp-dcae.rst index 2eaa8c93..aeba21fd 100644 --- a/docs/development/devtools/clamp-dcae.rst +++ b/docs/development/devtools/clamp-dcae.rst @@ -55,9 +55,9 @@ The test set focused on the following use cases: Creation of the Automation Composition: --------------------------------------- -A Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED". +An Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED". -- Upload a TOSCA template from the POLICY GUI. The definitions includes a kubernetes participant and control loop elements that deploys and configures a microservice in the kubernetes cluster. +- Upload a TOSCA template from the POLICY GUI. The definitions include a kubernetes participant and control loop elements that deploys and configures a microservice in the kubernetes cluster. Automation Composition element for kubernetes participant includes a helm chart information of DCAE microservice and the element for Http Participant includes the configuration entity for the microservice. :download:`Sample Tosca template <tosca/pairwise-testing.yml>` @@ -88,7 +88,7 @@ Verification: - DCAE service PMSH is deployed in to the kubernetes cluster. PMSH pods are in RUNNING state. `helm ls -n <namespace>` - The helm deployment of dcaegen2 service PMSH is listed. - `kubectl get pod -n <namespace>` - The PMSH pods are deployed, up and Running. + `kubectl get pod -n <namespace>` - The PMSH pods are deployed, up and running. - The subscription configuration for PMSH microservice from the TOSCA definitions are updated in the Consul server. The configuration can be verified on the Consul server UI `http://<CONSUL-SERVER_IP>/ui/#/dc1/kv/` diff --git a/docs/development/devtools/clamp-policy.rst b/docs/development/devtools/clamp-policy.rst index 3b3b90f5..20089b4e 100644 --- a/docs/development/devtools/clamp-policy.rst +++ b/docs/development/devtools/clamp-policy.rst @@ -45,9 +45,9 @@ The test set focused on the following use cases: Creation of the Automation Composition: --------------------------------------- -A Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED". +An Automation Composition is created by commissioning a Tosca template with Automation Composition definitions and instantiating the Automation Composition with the state "UNINITIALISED". -- Upload a TOSCA template from the POLICY GUI. The definitions includes a policy participant and a Automation Composition element that creates and deploys required policies. :download:`Sample Tosca template <tosca/pairwise-testing.yml>` +- Upload a TOSCA template from the POLICY GUI. The definitions include a policy participant and an Automation Composition element that creates and deploys required policies. :download:`Sample Tosca template <tosca/pairwise-testing.yml>` .. image:: images/cl-commission.png diff --git a/docs/development/devtools/clamp-s3p.rst b/docs/development/devtools/clamp-s3p.rst index aa435c59..639b295d 100644 --- a/docs/development/devtools/clamp-s3p.rst +++ b/docs/development/devtools/clamp-s3p.rst @@ -73,8 +73,8 @@ Stability test plan was triggered for 72 hours. .. Note:: .. container:: paragraph - - The assertions of state changes are not completely taken care of, as the stability is ran with acm componenets + + The assertions of state changes are not completely taken care of, as the stability is ran with acm components alone, and not including complete policy framework deployment, which makes it difficult for actual state changes from PASSIVE to RUNNING etc to happen. diff --git a/docs/development/devtools/clamp-smoke.rst b/docs/development/devtools/clamp-smoke.rst index 80f8c3b7..478ba8eb 100644 --- a/docs/development/devtools/clamp-smoke.rst +++ b/docs/development/devtools/clamp-smoke.rst @@ -22,7 +22,7 @@ This article assumes that: * You have copied the settings.xml from oparent to *~/.m2/* directory * You have added settings to access the ONAP Nexus to your M2 configuration, see `Maven Settings Example <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_ (bottom of the linked page) -The procedure documented in this article has been verified using Unbuntu 20.04 LTS VM. +The procedure documented in this article has been verified using Ubuntu 20.04 LTS VM. Cloning CLAMP automation composition and all dependency ******************************************************* @@ -204,7 +204,7 @@ Running a MariaDb Instance Assuming you have successfully built the codebase using the instructions above. There are two requirements for the Clamp automation composition component to run, one of them is a running MariaDb database instance. The easiest way to do this is to run the docker image locally. -An sql such as the one below can be used to build the SQL initialization. Create the *mariadb.sql* file in the directory *~/git*. +A sql such as the one below can be used to build the SQL initialization. Create the *mariadb.sql* file in the directory *~/git*. .. code-block:: SQL @@ -411,4 +411,4 @@ Run the following docker composition: command: /bin/sh -c "pip install --no-cache-dir requests && pip install --no-cache-dir simplejson && python -u /script/third_party_proxy.py -v true --port 8085 --root /thirdparty --proxyaddress third-party-proxy:8085" -Run DMaaP simulator, and than run CLAMP Acm using java. +Run DMaaP simulator, and then run CLAMP Acm using java. diff --git a/docs/development/devtools/db-migrator-smoke.rst b/docs/development/devtools/db-migrator-smoke.rst index 54673779..74b8eddd 100644 --- a/docs/development/devtools/db-migrator-smoke.rst +++ b/docs/development/devtools/db-migrator-smoke.rst @@ -1,4 +1,4 @@ -.. This work is licensed under a Creative Commons Attribution +.. This work is licensed under a Creative Commons Attribution .. 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 @@ -317,7 +317,7 @@ Modify db_migrator_policy_init.sh - remove any lines referencing upgrade and add Make/Redeploy to run downgrade -Check the tables to ensure the number records is the same. +Check the tables to ensure the number of records is the same. .. code:: :number-lines: @@ -374,7 +374,7 @@ Modify db_migrator_policy_init.sh - remove any lines referencing downgrade and a Make/Redeploy to run upgrade -Check the tables to ensure the number records is the same. +Check the tables to ensure the number of records is the same. .. code:: :number-lines: @@ -414,7 +414,7 @@ Check the pdp table to ensure the LASTUPDATE column has been added and the value - 0900 .. note:: - The number of records added may vary depnding on the number of retries. + The number of records added may vary depending on the number of retries. With addition of Postgres support to db-migrator, these tests can be also performed on a Postgres version of database. In addition, scripts running the aforementioned scenarios can be found under `smoke-tests` folder on db-migrator code base. diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst index e3a34941..787af683 100644 --- a/docs/development/devtools/devtools.rst +++ b/docs/development/devtools/devtools.rst @@ -22,7 +22,7 @@ This article assumes that: * You have copied the settings.xml from oparent to *~/.m2/* directory * You have added settings to access the ONAP Nexus to your M2 configuration, see `Maven Settings Example <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_ (bottom of the linked page) -The procedure documented in this article has been verified to work on a MacBook laptop running macOS Mojave Version 10.14.6 and an Unbuntu 18.06 VM. +The procedure documented in this article has been verified to work on a MacBook laptop running macOS Mojave Version 10.14.6 and an Ubuntu 18.06 VM. Cloning All The Policy Repositories *********************************** @@ -348,8 +348,8 @@ the Policy Framework works in a full ONAP deployment. Generating Swagger Documentation ******************************** The `Policy Parent Integration POM <https://github.com/onap/policy-parent/blob/master/integration/pom.xml>`_ contains a *generateSwaggerDocs* profile. This -profile can be activated on any module that has a Swagger endopint. When active, this profile creates a tarball in Nexus with the name -*<project-artifactId>-swagger-docs.tar.gz*. The tarball contains the fillowing files: +profile can be activated on any module that has a Swagger endpoint. When active, this profile creates a tarball in Nexus with the name +*<project-artifactId>-swagger-docs.tar.gz*. The tarball contains the following files: .. code-block:: bash @@ -368,7 +368,7 @@ The profile is activated when: See the `CLAMP runtime POM <https://github.com/onap/policy-clamp/blob/master/runtime/pom.xml>`_ for an example of the usage of this property. -2. Unit tests are being executed in the build, in other wirds when the *skipTests* flag is *false*. +2. Unit tests are being executed in the build, in other words when the *skipTests* flag is *false*. You **must** create a unit test in your module that generates the following file: @@ -419,7 +419,7 @@ Running in Eclipse Specifying a local configuration file +++++++++++++++++++++++++++++++++++++ -You may specify a local configuration file instead of *src/test/resources/simParameters.json* on the command line or as an arument in the run configuration in eclipse: +You may specify a local configuration file instead of *src/test/resources/simParameters.json* on the command line or as an argument in the run configuration in eclipse: .. code-block:: json diff --git a/docs/development/devtools/distribution-smoke.rst b/docs/development/devtools/distribution-smoke.rst index 8afa715a..c0e3cb1d 100644 --- a/docs/development/devtools/distribution-smoke.rst +++ b/docs/development/devtools/distribution-smoke.rst @@ -7,7 +7,8 @@ Policy Distribution Smoke Test ################################ -The policy-distribution smoke testing is executed against a custom ONAP docker installation as defined in the "policy/docker/csit/docker-compose-distribution-smoke.yml" +The policy-distribution smoke testing is executed against a custom ONAP docker installation as defined in the docker compose file in "policy/docker/csit/". +The policy-distribution configuration file is located in "docker/csit/config/distribution/". This test verifies the execution of the REST api's exposed by the component to make sure the CSAR Decoding and Forwarding works as expected. General Setup @@ -28,9 +29,9 @@ This script will compose the ONAP components used during the smoke tests are: - Policy Drools-PDP to deploy & undeploy policies. And send heartbeats to PAP. - Policy Xacml-PDP to deploy & undeploy policies. And send heartbeats to PAP. -- Policy Distribution to test the Decoding and Farwarding functions. +- Policy Distribution to test the Decoding and Forwarding functions. -Use this script to easly bring down the containers : +Use this script to easily bring down the containers : .. code-block:: bash @@ -129,7 +130,7 @@ Expected success-count result [{"policy-type":"onap.policies.native.Apex","policy-type-version":"1.0.0","policy-id":"operational.apex.sampledomain","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0},{"policy-type":"onap.policies.Naming","policy-type-version":"1.0.0","policy-id":"SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP","policy-version":"1.0.0","success-count":1,"failure-count":0,"incomplete-count":0}] Or download & execute the steps in postman collection for verifying policy-pap component. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. `Policy Framework Administration API <https://github.com/onap/policy-pap/blob/master/postman/pap-api-collection.json>`_ diff --git a/docs/development/devtools/drools-s3p.rst b/docs/development/devtools/drools-s3p.rst index 1586379e..22c1b47d 100644 --- a/docs/development/devtools/drools-s3p.rst +++ b/docs/development/devtools/drools-s3p.rst @@ -84,7 +84,7 @@ For 72 hours the following 5 scenarios ran in parallel: - vCPE success scenario - vCPE failure scenario (failure returned by simulated APPC recipient through DMaaP). - vDNS success scenario. -- vDNS failure scenario (failure by introducing in the DCAE ONSET a non-existant vserver-name reference). +- vDNS failure scenario (failure by introducing in the DCAE ONSET a non-existent vserver-name reference). - vFirewall success scenario. Five threads ran in parallel, one for each scenario, back to back with no pauses. The transactions were initiated diff --git a/docs/development/devtools/images/pol-part-controlloop-creation-ver.png b/docs/development/devtools/images/pol-part-clampacm-creation-ver.png Binary files differindex 36fdfafa..36fdfafa 100644 --- a/docs/development/devtools/images/pol-part-controlloop-creation-ver.png +++ b/docs/development/devtools/images/pol-part-clampacm-creation-ver.png diff --git a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-deploy-ver.png b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-deploy-ver.png Binary files differindex 10f3da77..10f3da77 100644 --- a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-deploy-ver.png +++ b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-deploy-ver.png diff --git a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-nf.png b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-nf.png Binary files differindex 1f10411e..1f10411e 100644 --- a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-nf.png +++ b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-nf.png diff --git a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-undep-ver.png b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-undep-ver.png Binary files differindex d023a83b..d023a83b 100644 --- a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-undep-ver.png +++ b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-undep-ver.png diff --git a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-ver.png b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-ver.png Binary files differindex 0be48b17..0be48b17 100644 --- a/docs/development/devtools/images/pol-part-controlloop-pmcontrol-ver.png +++ b/docs/development/devtools/images/pol-part-clampacm-pmcontrol-ver.png diff --git a/docs/development/devtools/images/pol-part-controlloop-sirisha-nf.png b/docs/development/devtools/images/pol-part-clampacm-test-policy-nf.png Binary files differindex 293c7607..293c7607 100644 --- a/docs/development/devtools/images/pol-part-controlloop-sirisha-nf.png +++ b/docs/development/devtools/images/pol-part-clampacm-test-policy-nf.png diff --git a/docs/development/devtools/images/pol-part-controlloop-sirisha-ver.png b/docs/development/devtools/images/pol-part-clampacm-test-policy-ver.png Binary files differindex dfa4a9d1..dfa4a9d1 100644 --- a/docs/development/devtools/images/pol-part-controlloop-sirisha-ver.png +++ b/docs/development/devtools/images/pol-part-clampacm-test-policy-ver.png diff --git a/docs/development/devtools/pap-s3p.rst b/docs/development/devtools/pap-s3p.rst index 4043a144..df9d5c7c 100644 --- a/docs/development/devtools/pap-s3p.rst +++ b/docs/development/devtools/pap-s3p.rst @@ -17,7 +17,7 @@ Setup Details +++++++++++++ - Policy-PAP along with all policy components deployed as part of a full ONAP OOM deployment. -- A second instance of APEX-PDP is spun up in the setup. Update the configuration file(OnapPfConfig.json) such that the PDP can register to the new group created by PAP in the tests. +- A second instance of APEX-PDP is spun up in the setup. Update the configuration file (OnapPfConfig.json) such that the PDP can register to the new group created by PAP in the tests. - Both tests were run via jMeter, which was installed on a separate VM. Stability Test of PAP @@ -90,7 +90,7 @@ Stability test plan was triggered for 72 hours. As part of the OOM deployment, another APEX-PDP pod is spun up with the pdpGroup name specified as 'sampleGroup'. After creating the new group called 'sampleGroup' as part of the test, a time delay of 2 minutes is added, so that the pdp is registered to the newly created group. - This has resulted in a spike in the Average time taken per request. But, this is required to make proper assertions, + This has resulted in a spike in the Average time taken per request. But this is required to make proper assertions, and also for the consolidated health check. **Test Statistics** diff --git a/docs/development/devtools/pap-smoke.rst b/docs/development/devtools/pap-smoke.rst index 07d143bd..a5f54c06 100644 --- a/docs/development/devtools/pap-smoke.rst +++ b/docs/development/devtools/pap-smoke.rst @@ -47,7 +47,7 @@ Create policies using policy-api In order to test policy-pap, we need to use policy-api component to create the policies. Download & execute the steps in postman collection for creating policies. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. `Policy Framework Lifecycle API <https://github.com/onap/policy-api/blob/master/postman/lifecycle-api-collection.json>`_ @@ -57,7 +57,7 @@ Make sure to skip the delete policy steps. Execute policy-pap testing -------------------------- Download & execute the steps in postman collection for verifying policy-pap component. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. `Policy Framework Administration API <https://github.com/onap/policy-pap/blob/master/postman/pap-api-collection.json>`_ diff --git a/docs/development/devtools/policy-cds.rst b/docs/development/devtools/policy-cds.rst index 35331a2f..be6fd319 100644 --- a/docs/development/devtools/policy-cds.rst +++ b/docs/development/devtools/policy-cds.rst @@ -50,8 +50,8 @@ 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 Automation Composition flow, the entities in AAI will be either created during orchestration phase or provisioned in AAI separately. -Download & execute the steps in postman collection for creating the entities along with it's dependencies. -The steps needs to be performed sequentially one after another. And no input is required from user. +Download & execute the steps in postman collection for creating the entities along with its dependencies. +The steps need to be performed sequentially one after another. And no input is required from user. :download:`Create VNF & PNF in AAI <postman/create-vnf-pnf-aai.postman_collection.json>` @@ -94,7 +94,7 @@ List of steps covered in the postman collection: - Delete both VNF & PNF policies at the end. Download & execute the steps in postman collection. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. :download:`Apex-PDP VNF & PNF Testing <postman/apex-pdp-vnf-pnf-testing.postman_collection.json>` @@ -118,7 +118,7 @@ List of steps covered in the postman collection: - Delete both VNF & PNF policies at the end. Download & execute the steps in postman collection. -The steps needs to be performed sequentially one after another. And no input is required from user. +The steps need to be performed sequentially one after another. And no input is required from user. :download:`Drools-PDP VNF & PNF Testing <postman/drools-pdp-vnf-pnf-testing.postman_collection.json>` diff --git a/docs/development/devtools/policy-gui-acm-smoke.rst b/docs/development/devtools/policy-gui-acm-smoke.rst index 8070204c..26da79b0 100644 --- a/docs/development/devtools/policy-gui-acm-smoke.rst +++ b/docs/development/devtools/policy-gui-acm-smoke.rst @@ -20,7 +20,7 @@ This document will serve as a guide to do smoke tests on the different component 2. Setup Guide ************** -This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. The IDE used in the examples here is Intellij but most or all of what is described should be the same across IDEs. +This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. The IDE used in the examples here is Intellij but most or all of what is described should be the same across IDEs. 2.1 Prerequisites ================= @@ -181,7 +181,7 @@ To start the acm runtime we need to go the "runtime-acm" directory in the clamp 2.3.8 Automation Composition GUI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -At this point, all of the components required to test out the acm gui are running.We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI. +At this point, all of the components required to test out the acm gui are running. We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI. Firstly, go to the GUI repo and navigate to "gui-clamp/ui-react". To setup for development, we must install the dependencies of the GUI. We can do this using the npm package manager. In the directory, simply run: @@ -264,7 +264,7 @@ and .. image:: images/gui/PolicySuccess.png -Following the same procedure as changeing the state to PASSIVE, we can then change to UNINITIALISED. This deletes the policies and policy types through the policy api and changes the overall state of the loop. we can then delete it from the Manage Instances table by clicking on Delete. +Following the same procedure as changing the state to PASSIVE, we can then change to UNINITIALISED. This deletes the policies and policy types through the policy api and changes the overall state of the loop. we can then delete it from the Manage Instances table by clicking on Delete. Decommissioning =============== diff --git a/docs/development/devtools/policy-participant-smoke.rst b/docs/development/devtools/policy-participant-smoke.rst index bf236351..031c2cb3 100644 --- a/docs/development/devtools/policy-participant-smoke.rst +++ b/docs/development/devtools/policy-participant-smoke.rst @@ -13,7 +13,7 @@ The Smoke testing of the policy participant is executed in a local CLAMP/Policy 2. Setup Guide ************** -This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are a number of prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. +This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. 2.1 Prerequisites ================= @@ -305,7 +305,7 @@ To perform the Smoke testing of the policy-participant we will be verifying the Creation of ACM: ************************ -A ACM is created by commissioning a Tosca template with ACM definitions and instantiating the ACM with the state "UNINITIALISED". +An ACM is created by commissioning a Tosca template with ACM definitions and instantiating the ACM with the state "UNINITIALISED". Using postman, commission a TOSCA template and instantiate using the following template: :download:`Tosca Service Template <tosca/tosca_service_template_pptnt_smoke.yaml>` diff --git a/docs/development/devtools/xacml-s3p.rst b/docs/development/devtools/xacml-s3p.rst index 7ef035d5..64a3cfe8 100644 --- a/docs/development/devtools/xacml-s3p.rst +++ b/docs/development/devtools/xacml-s3p.rst @@ -26,7 +26,7 @@ Running jmeter and ONAP OOM on the same VM may adversely impact the performance Summary ======= -The Performance test was executed, and the result analyzed, via: +The Performance test was executed, and the result analysed, via: .. code-block:: bash @@ -84,7 +84,7 @@ lab. This was running on a kubernetes pod having the following configuration: The test was run via jmeter, which was installed on the same VM. Running jmeter and ONAP OOM on the same VM may adversely impact the performance of the XACML-PDP being tested. -Due to the minimal nauture of this setup, the K8S cluster became overloaded on a couple of occasions during the test. +Due to the minimal nature of this setup, the K8S cluster became overloaded on a couple of occasions during the test. This resulted in a small number of errors and a greater maximum transaction time than normal. Summary |
