diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/development/devtools/testing/s3p/apex-s3p-results/apex_performance_results.png | bin | 172847 -> 83623 bytes | |||
| -rw-r--r-- | docs/development/devtools/testing/s3p/apex-s3p-results/apex_stability_results.png | bin | 180140 -> 106062 bytes | |||
| -rw-r--r-- | docs/development/devtools/testing/s3p/apex-s3p.rst | 26 | ||||
| -rw-r--r-- | docs/system-attributes/policy-db-migrator.rst | 43 |
4 files changed, 46 insertions, 23 deletions
diff --git a/docs/development/devtools/testing/s3p/apex-s3p-results/apex_performance_results.png b/docs/development/devtools/testing/s3p/apex-s3p-results/apex_performance_results.png Binary files differindex 67aa529f..7ddb0a67 100644 --- a/docs/development/devtools/testing/s3p/apex-s3p-results/apex_performance_results.png +++ b/docs/development/devtools/testing/s3p/apex-s3p-results/apex_performance_results.png diff --git a/docs/development/devtools/testing/s3p/apex-s3p-results/apex_stability_results.png b/docs/development/devtools/testing/s3p/apex-s3p-results/apex_stability_results.png Binary files differindex c849204f..8dddd470 100644 --- a/docs/development/devtools/testing/s3p/apex-s3p-results/apex_stability_results.png +++ b/docs/development/devtools/testing/s3p/apex-s3p-results/apex_stability_results.png diff --git a/docs/development/devtools/testing/s3p/apex-s3p.rst b/docs/development/devtools/testing/s3p/apex-s3p.rst index f756e4b5..0bbb0363 100644 --- a/docs/development/devtools/testing/s3p/apex-s3p.rst +++ b/docs/development/devtools/testing/s3p/apex-s3p.rst @@ -19,7 +19,7 @@ Deploying ONAP using OOM ------------------------ APEX-PDP along with all policy components are deployed as part of a full Policy Framework deployment. -At a minimum, the following components are needed: policy, mariadb-galera, prometheus and dmaap. +At a minimum, the following components are needed: policy, mariadb-galera, prometheus and kafka. The S3P tests utilise the ./run-s3p-tests script in the apex component. This will setup the microk8s environment, deploy policy and prometheus, expose the services so they can be reached by JMeter, install JMeter and run the tests based on @@ -28,11 +28,11 @@ the arguments provided. Set up policy-models-simulator ------------------------------ -Policy-models-simulator is deployed to use the DMaaP simulator during policy execution. +Kafka is deployed and is used during policy execution. Simulator configurations used are available in apex-pdp repository: testsuites/apex-pdp-stability/src/main/resources/simulatorConfig/ -The published port 30904 is used in JMeter for the DMaaP simulator. +The published port 29092 is used in JMeter for the Kafka. JMeter Tests ------------ @@ -48,8 +48,8 @@ Both tests were run via jMeter. .. Note:: 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. + There are test cases where up to 80 events are expected on the Kafka topic. + Kafka is used to keep it simple and avoid any message pickup timing related issues. Stability Test of APEX-PDP ++++++++++++++++++++++++++ @@ -77,20 +77,18 @@ Once the policies are created and deployed to APEX-PDP by the setup thread, five - **Healthcheck** - checks the health status of APEX-PDP - **Prometheus Metrics** - checks that APEX-PDP is exposing prometheus metrics -- **Test Simplecontrolloop policy success case** - Send a trigger event to *unauthenticated.DCAE_CL_OUTPUT* DMaaP topic. +- **Test Simplecontrolloop policy success case** - Send a trigger event to *unauthenticated.DCAE_CL_OUTPUT* Kafka topic. If the policy execution is successful, 3 different notification events are sent to *APEX-CL-MGT* topic by each one of the 5 threads. So, it is checked if 15 notification messages are received in total on *APEX-CL-MGT* topic with the relevant messages. -- **Test Simplecontrolloop policy failure case** - Send a trigger event with invalid pnfName to *unauthenticated.DCAE_CL_OUTPUT* DMaaP topic. +- **Test Simplecontrolloop policy failure case** - Send a trigger event with invalid pnfName to *unauthenticated.DCAE_CL_OUTPUT* Kafka topic. The policy execution is expected to fail due to AAI failure response. 2 notification events are expected on *APEX-CL-MGT* topic by a thread in this case. It is checked if 10 notification messages are received in total on *APEX-CL-MGT* topic with the relevant messages. -- **Test Example policy success case** - Send a trigger event to *unauthenticated.DCAE_POLICY_EXAMPLE_OUTPUT* DMaaP topic. +- **Test Example policy success case** - Send a trigger event to *unauthenticated.DCAE_POLICY_EXAMPLE_OUTPUT* Kafka topic. If the policy execution is successful, 4 different notification events are sent to *APEX-CL-MGT* topic by each one of the 5 threads. So, it is checked if 20 notification messages are received in total on *APEX-CL-MGT* topic with the relevant messages. -- **Test Example policy failure case** - Send a trigger event with invalid vnfName to *unauthenticated.DCAE_POLICY_EXAMPLE_OUTPUT* DMaaP topic. +- **Test Example policy failure case** - Send a trigger event with invalid vnfName to *unauthenticated.DCAE_POLICY_EXAMPLE_OUTPUT* Kafka topic. The policy execution is expected to fail due to AAI failure response. 2 notification events are expected on *APEX-CL-MGT* topic by a thread in this case. So, it is checked if 10 notification messages are received in total on *APEX-CL-MGT* topic with the relevant messages. -- **Clean up DMaaP notification topic** - DMaaP notification topic which is *APEX-CL-MGT* is cleaned up after each test to make sure that one failure doesn't lead to cascading errors. - Teardown Phase """""""""""""" @@ -119,7 +117,7 @@ The following steps can be used to configure the parameters of test plan. API_PORT Port number of API for making REST API calls such as create/delete of policy APEX_PORT Port number of APEX for making REST API calls such as healthcheck/metrics SIM_HOST IP Address or hostname running policy-models-simulator - DMAAP_PORT Port number of DMaaP simulator for making REST API calls such as reading notification events + KAFKA_PORT Port number of Kafka bootstrap server for sending message events wait Wait time if required after a request (in milliseconds) threads Number of threads to run test cases in parallel threadsTimeOutInMs Synchronization timer for threads running in parallel (in milliseconds) @@ -143,7 +141,7 @@ Stability test plan was triggered for 72 hours. There were no failures during th ======================= ================= ================== ================================== **Total # of requests** **Success %** **Error %** **Average time taken per request** ======================= ================= ================== ================================== -112245 99.47 % 0.53 % 2.309 sec. +312366 100 % 0 % 4148ms ======================= ================= ================== ================================== **JMeter Screenshot** @@ -191,7 +189,7 @@ Test results are shown as below. ======================= ================= ================== ================================== **Total # of requests** **Success %** **Error %** **Average time taken per request** ======================= ================= ================== ================================== -12486 99.32 % 0.68 % 576.64 ms +344624 100 % 0 % 4178 ms ======================= ================= ================== ================================== **JMeter Screenshot** diff --git a/docs/system-attributes/policy-db-migrator.rst b/docs/system-attributes/policy-db-migrator.rst index 840137e9..81019efe 100644 --- a/docs/system-attributes/policy-db-migrator.rst +++ b/docs/system-attributes/policy-db-migrator.rst @@ -8,7 +8,7 @@ Using Policy DB Migrator ######################## Policy DB Migrator is a set of shell scripts used to -install the database tables required to run ONAP Policy Framework. +install the database tables required to run ONAP Policy Framework and ACM. .. note:: Currently the Istanbul versions of the PAP and API components require @@ -53,7 +53,7 @@ These script can take up to four parameters: - upgrade/downgrade/report * - schema - -s - - policyadmin + - policyadmin/clampacm * - to - -t - 0800/0900 @@ -76,7 +76,7 @@ to run and connect to the database. * - SQL_HOST - mariadb * - SQL_DB - - policyadmin + - policyadmin/clampacm * - SQL_USER - policy_user * - SQL_PASSWORD @@ -98,7 +98,7 @@ to run and connect to the database. * - SQL_HOST - postgres * - SQL_DB - - policyadmin + - policyadmin/clampacm * - SQL_USER - policy_user * - SQL_PASSWORD @@ -119,7 +119,7 @@ Prior to upgrading the following script is run: /opt/app/policy/bin/prepare_upgrade.sh <SCHEMA NAME> -This will copy the upgrade files from ``/home/policy/${SCRIPT_DIRECTORY}`` to ``$POLICY_HOME/etc/db/migration/<SCHEMA NAME>/${SCRIPT_DIRECTORY}/`` +This will copy the upgrade files from ``/home/${SCHEMA}/${SCRIPT_DIRECTORY}`` to ``$POLICY_HOME/etc/db/migration/<SCHEMA NAME>/${SCRIPT_DIRECTORY}/`` Each individual sql file that makes up that release will be run as part of the upgrade. @@ -132,7 +132,7 @@ Prior to downgrading the following script is run: /opt/app/policy/bin/prepare_downgrade.sh <SCHEMA NAME> -This will copy the downgrade files from ``/home/policy/${SCRIPT_DIRECTORY}`` to ``$POLICY_HOME/etc/db/migration/<SCHEMA NAME>/${SCRIPT_DIRECTORY}/`` +This will copy the downgrade files from ``/home/${SCHEMA}/${SCRIPT_DIRECTORY}`` to ``$POLICY_HOME/etc/db/migration/<SCHEMA NAME>/${SCRIPT_DIRECTORY}/`` Each individual sql file that makes up that release will be run as part of the downgrade. @@ -199,7 +199,7 @@ Console output will also show the sql script command as in the example below: migration schema ================ -The migration schema contains two tables which belong to ``db-migrator``. +The migration schema contains three tables which belong to ``db-migrator``. * schema_versions - table to store the schema version currently installed by ``db-migrator`` @@ -210,7 +210,9 @@ The migration schema contains two tables which belong to ``db-migrator``. * - name - version * - policyadmin - - 0900 + - 1400 + * - clampacm + - 1400 * policyadmin_schema_changelog - table which stores a record of each sql file that has been run @@ -235,6 +237,29 @@ The migration schema contains two tables which belong to ``db-migrator``. - 1 - 2021-09-13 09:09:26 +* clampacm_schema_changelog - table which stores a record of each sql file that has been run + +.. list-table:: + :widths: 10 40 10 10 10 20 10 20 + :header-rows: 1 + + * - ID + - script + - operation + - from_version + - to_version + - tag + - success + - atTime + * - 1 + - 0100-automationcomposition.sql + - upgrade + - 0 + - 1400 + - 1309210909250800u + - 1 + - 2024-04-24 09:09:26 + * ID: Sequence number of the operation * script: name of the sql script which was run * operation: operation type - upgrade/downgrade @@ -340,7 +365,7 @@ If the target version of your upgrade or downgrade is the same as the current ve no sql files are run. If an upgrade is run on a database where tables already exist in the policy schema, the -current schema version is set to 0800 and only sql scripts from later versions are run. +current schema version is set to 1300 and only sql scripts from later versions are run. .. note:: It is advisable to take a backup of your database prior to running this utility. |
