diff options
| -rw-r--r-- | docs/development/devtools/devtools.rst | 106 | ||||
| -rw-r--r-- | docs/drools/pdpdApps.rst | 31 | ||||
| -rw-r--r-- | docs/drools/pdpdEngine.rst | 100 | ||||
| -rw-r--r-- | docs/installation/docker.rst | 7 | ||||
| -rw-r--r-- | docs/pap/InternalPapPdp.rst | 57 | ||||
| -rw-r--r-- | docs/system-attributes/policy-db-migrator.rst | 12 |
6 files changed, 53 insertions, 260 deletions
diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst index ecddbf52..4e63fdbc 100644 --- a/docs/development/devtools/devtools.rst +++ b/docs/development/devtools/devtools.rst @@ -234,34 +234,17 @@ With docker images: Developing and Debugging each Policy Component ********************************************** -Running a MariaDb Instance -++++++++++++++++++++++++++ - -The Policy Framework requires a MariaDb instance running. The easiest way to do this is to run a docker image locally. - -One example on how to do this is to use the scripts used by the policy/api S3P tests. - -`Simulator Setup Script Example <https://gerrit.onap.org/r/gitweb?p=policy/api.git;a=tree;f=testsuites/stability/src/main/resources/simulatorsetup;h=9038413f67cff2e2a79d6345f198f96ee0c57de1;hb=refs/heads/master>`_ - - .. code-block:: bash - - cd ~/git/onap/api/testsuites/stability/src/main/resources/simulatorsetup - ./setup_components.sh - -Another example on how to run the MariaDb is using the docker compose file used by the Policy API CSITs: - -`Example Compose Script to run MariaDB <https://gerrit.onap.org/r/gitweb?p=integration/csit.git;a=blob;f=scripts/policy/docker-compose-api.yml;h=e32190f1e6cb6d9b64ddf53a2db2c746723a0c6a;hb=refs/heads/master>`_ Running the API component standalone ++++++++++++++++++++++++++++++++++++ Assuming you have successfully built the codebase using the instructions above. The only requirement for the API -component to run is a running MariaDb database instance. The easiest way to do this is to run the docker image, please -see the mariadb documentation for the latest information on doing so. Once the mariadb is up and running, a -configuration file must be provided to the api in order for it to know how to connect to the mariadb. You can locate -the default configuration file in the packaging of the api component: +component to run is a running MariaDb/Postgres database instance. The easiest way to do this is to run the docker +image, please see the official documentation for the latest information on doing so. Once the database is up and +running, a configuration file must be provided to the api in order for it to know how to connect to the database. +You can locate the default configuration file in the packaging of the api component: -`Default Policy API Configuration <https://gerrit.onap.org/r/gitweb?p=policy/api.git;a=blob;f=packages/policy-api-tarball/src/main/resources/etc/apiParameters.yaml;h=2c19199a8a889cb0ab203334182662fe15e1635e;hb=refs/heads/master>`_ +`Default Policy API Configuration <https://github.com/onap/policy-api/blob/master/packages/policy-api-tarball/src/main/resources/etc/apiParameters.yaml>`_ You will want to change the fields pertaining to "host", "port" and "databaseUrl" to your local environment settings and start the policy-api springboot application either using your IDE of choice or using the run goal from Spring Boot @@ -272,22 +255,21 @@ Running the API component using Docker Compose An example of running the api using a docker compose script is located in the Policy Integration CSIT test repository. -`Policy CSIT API Docker Compose <https://gerrit.onap.org/r/gitweb?p=integration/csit.git;a=blob;f=scripts/policy/docker-compose-api.yml;h=e32190f1e6cb6d9b64ddf53a2db2c746723a0c6a;hb=refs/heads/master>`_ +`Policy CSIT Docker Compose <https://github.com/onap/policy-docker/blob/master/compose/compose.yaml>`_ Running the PAP component standalone ++++++++++++++++++++++++++++++++++++ -Once you have successfully built the PAP codebase, a running MariaDb database and DMaaP instance will also be required -to start up the application. For MariaDb instance, the easiest way is to run the docker image, please see the mariadb -documentation for the latest information on doing so. For DMaaP, the easiest way during development is to run the DMaaP -simulator which is explained in the below sections. Once the mariadb and DMaaP are running, a configuration file must -be provided to the PAP component in order for it to know how to connect to the mariadb and DMaaP along with other -relevant configuration details. You can locate the default configuration file in the packaging of the PAP component: +Once you have successfully built the PAP codebase, a running MariaDb/Postgres database and Kafka instance will also be +required to start up the application. To start database and Kafka, check official documentation on how to run an +instance of each. After database and Kafka are up and running, a configuration file must be provided to the PAP +component in order for it to know how to connect to the database and Kafka along with other relevant configuration +details. You can locate the default configuration file in the packaging of the PAP component: -`Default PAP Configuration <https://gerrit.onap.org/r/gitweb?p=policy/pap.git;a=blob;f=packages/policy-pap-tarball/src/main/resources/etc/papParameters.yaml;h=06dd45f4946fd0a11ed8ef859f8fc5bcf409a3f0;hb=HEAD>`_ +`Default PAP Configuration <https://github.com/onap/policy-pap/blob/master/packages/policy-pap-tarball/src/main/resources/etc/papParameters.yaml>`_ -Update the fields related to MariaDB, DMaaP and the RestServer for the application as per your local environment settings. -Then to start the application, just run the Spring Boot application using IDE or command line. +Update the fields related to database, Kafka and the RestServer for the application as per your local environment +settings. Then to start the application, just run the Spring Boot application using IDE or command line. Running the Smoke Tests @@ -315,8 +297,8 @@ familiar with the Policy Framework components and test any local changes. Running the Stability/Performance Tests *************************************** -The following links contain instructions on how to run the S3P Stability and Performance tests. These may be helpful to developers to become -familiar with the Policy Framework components and test any local changes. +The following links contain instructions on how to run the S3P Stability and Performance tests. These may be helpful +to developers to become familiar with the Policy Framework components and test any local changes. .. toctree:: :maxdepth: 2 @@ -334,8 +316,8 @@ familiar with the Policy Framework components and test any local changes. Running the Pairwise Tests ************************** -The following links contain instructions on how to run the pairwise tests. These may be helpful to developers check that -the Policy Framework works in a full ONAP deployment. +The following links contain instructions on how to run the pairwise tests. These may be helpful to developers check +that the Policy Framework works in a full ONAP deployment. .. toctree:: :maxdepth: 1 @@ -426,7 +408,8 @@ To test these images, CSITs will be run. Running Policy Components Locally ********************************* -The following page outlines how to run the policy framework components locally using IntelliJ, Eclipse and the Command Line. +The following page outlines how to run the policy framework components locally using IntelliJ, +Eclipse and the Command Line. .. toctree:: :maxdepth: 1 @@ -457,57 +440,14 @@ Using the Swagger-UI maven dependency Swagger HTML documentation can be accessed - The generated swagger.json can be accessed at: *https://service_IP:service_port/v2/api-docs* - Swagger UI can be accessed at: *https://service_IP:service_port/swagger-ui/index.html* -Running the DMaaP Simulator during Development -********************************************** -It is sometimes convenient to run the DMaaP simulator during development. You can run it from the command line using Maven or from within your IDE. - -Running on the Command Line -+++++++++++++++++++++++++++ -1. Check out the policy models repository -2. Go to the *models-sim/policy-models-simulators* subdirectory in the policy-models repo -3. Run the following Maven command: - - .. code-block:: bash - - mvn exec:java -Dexec.mainClass=org.onap.policy.models.simulators.Main -Dexec.args="src/test/resources/simParameters.json" - -Running in Eclipse -++++++++++++++++++ -1. Check out the policy models repository -2. Go to the *models-sim/policy-models-simulators* module in the policy-models repo -3. Specify a run configuration using the class *org.onap.policy.models.simulators.Main* as the main class -4. Specify an argument of *src/test/resources/simParameters.json* to the run configuration -5. Run the configuration - -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 argument in the run configuration in eclipse: - -.. code-block:: json - - { - "dmaapProvider": { - "name": "DMaaP simulator", - "topicSweepSec": 900 - }, - "restServers": [ - { - "name": "DMaaP simulator", - "providerClass": "org.onap.policy.models.sim.dmaap.rest.DmaapSimRestControllerV1", - "host": "localhost", - "port": 3904, - "https": false - } - ] - } Bringing up Strimzi-Kafka Deploment with Policy Framework ********************************************************* -This page will explain how to setup a local Kubernetes cluster and minimal helm setup to run and deploy Policy Framework on a single host. +This page will explain how to setup a local Kubernetes cluster and minimal helm setup to run and deploy +Policy Framework on a single host. -This is meant for a development purpose only as we are going to use microk8s in this page +This is meant for a development purpose only as we are going to use microk8s in this page: .. toctree:: :maxdepth: 1 diff --git a/docs/drools/pdpdApps.rst b/docs/drools/pdpdApps.rst index dfb67515..6dceee5f 100644 --- a/docs/drools/pdpdApps.rst +++ b/docs/drools/pdpdApps.rst @@ -44,9 +44,9 @@ for the latest images: .. code-block:: bash - docker pull onap/policy-pdpd-cl:1.8.2 + docker pull onap/policy-pdpd-cl:3.0.0 -At the time of this writing *1.8.2* is the latest version. +At the time of this writing *3.0.0* is the latest version. The *onap/policy-pdpd-cl* image extends the *onap/policy-drools* image with the *usecases* controller that realizes the *control loop* application. @@ -120,10 +120,6 @@ The enabled features in the *onap/policy-pdpd-cl* image are: - **controlloop-management**: generic controller capabilities. - **controlloop-usecases**: new *controller* introduced in the guilin release to realize the ONAP use cases. -The following features are installed but disabled: - -- **controlloop-tdjam**: experimental java-only *controller* to be deprecated post guilin. -- **controlloop-utils**: *actor* simulators. Control Loops Transaction (controlloop-trans) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -146,11 +142,6 @@ It is the *guilin* release implementation of the ONAP use cases. It relies on the new *Actor* model framework to carry out a policy's execution. -TDJAM Controller (controlloop-tdjam) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This is an experimental, java-only controller that will be deprecated after the -guilin release. Utilities (controlloop-utils) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -273,10 +264,6 @@ First create an environment file (in this example *env.conf*) to configure the P DCAE_SERVERS=localhost DCAE_CONSUMER_GROUP=dcae.policy.shared - # Open DMaaP - - DMAAP_SERVERS=localhost - # AAI AAI_HOST=localhost @@ -311,18 +298,6 @@ First create an environment file (in this example *env.conf*) to configure the P Configuration ~~~~~~~~~~~~~ -noop.pre.sh -""""""""""" - -In order to avoid the noise in the logs that relate to dmaap configuration, a startup script (*noop.pre.sh*) is added -to convert *dmaap* endpoints to *noop* in the host directory to be mounted. - -.. code-block:: bash - - #!/bin/bash -x - - sed -i "s/^dmaap/noop/g" $POLICY_HOME/config/*.properties - features.pre.sh """"""""""""""" @@ -878,7 +853,7 @@ The reader can also look at the `policy/docker repository <https://github.com/on More specifically, these directories have examples of other PDP-D Control Loop configurations: * `plans <https://github.com/onap/policy-docker/tree/master/compose>`__: startup & teardown scripts. -* `scripts <https://github.com/onap/policy-docker/blob/master/compose>`__: docker-compose files. +* `scripts <https://github.com/onap/policy-docker/blob/master/compose/compose.yaml>`__: docker-compose file. * `tests <https://github.com/onap/policy-docker/blob/master/csit/resources/tests/drools-applications-test.robot>`__: test plan. Additional information diff --git a/docs/drools/pdpdEngine.rst b/docs/drools/pdpdEngine.rst index 6ad4790c..d943d561 100644 --- a/docs/drools/pdpdEngine.rst +++ b/docs/drools/pdpdEngine.rst @@ -40,11 +40,11 @@ Docker Image ~~~~~~~~~~~~ Check the *drools-pdp* `released versions <https://wiki.onap.org/display/DW/Policy+Framework+Project%3A+Component+Versions>`__ page for the latest versions. -At the time of this writing *1.8.2* is the latest version. +At the time of this writing *3.0.0* is the latest version. .. code-block:: bash - docker pull onap/policy-drools:1.8.2 + docker pull onap/policy-drools:3.0.0 A container instantiated from this image will run under the non-priviledged *policy* account. @@ -60,7 +60,7 @@ The following command can be used to explore the directory layout. .. code-block:: bash - docker run --rm -it nexus3.onap.org:10001/onap/policy-drools:1.8.2 -- bash + docker run --rm -it nexus3.onap.org:10001/onap/policy-drools:3.0.0 -- bash Communication Endpoints ======================= @@ -674,16 +674,6 @@ A feature is packaged in a *feature-<name>.zip* and has this internal layout: # of pdp-d that are necessary for <feature-name> to operate # correctly. # lib/feature the single feature jar that implements the feature. - # [db] database directory, if the feature contains sql. - # [db]/<db-name> database to which underlying sql scripts should be applied. - # ideally, <db-name> = <feature-name> so it is easily to associate - # the db data with a feature itself. In addition, since a feature is - # a somewhat independent isolated unit of functionality,the <db-name> - # database ideally isolates all its data. - # [db]/<db-name>/sql directory with all the sql scripts. - # [db]/<db-name>/sql/<sql-scripts> for this feature, sql - # upgrade scripts should be suffixed with ".upgrade.sql" - # and downgrade scripts should be suffixed with ".downgrade.sql" # [artifacts] maven artifacts to be deployed in a maven repository. # [artifacts]/<artifact> maven artifact with identifiable maven coordinates embedded # in the artifact. @@ -835,41 +825,13 @@ See the `feature-distributed-locking sql directory <https://git.onap.org/policy/docker/tree/policy-db-migrator/src/main/docker/config/pooling/sql>`__ for an example of upgrade/downgrade scripts. -The following command will provide a report on the upgrade or downgrade activies: - -.. code-block:: bash - - db-migrator -s ALL -o report - -For example in the official guilin delivery: - -.. code-block:: bash - - policy@dev-drools-0:/tmp/policy-install$ db-migrator -s ALL -o report - +---------+---------+ - | name | version | - +---------+---------+ - | pooling | 1811 | - +---------+---------+ - +-------------------------------------+-----------+---------+---------------------+ - | script | operation | success | atTime | - +-------------------------------------+-----------+---------+---------------------+ - | 1804-distributedlocking.upgrade.sql | upgrade | 1 | 2020-05-22 19:33:09 | - | 1811-distributedlocking.upgrade.sql | upgrade | 1 | 2020-05-22 19:33:09 | - +-------------------------------------+-----------+---------+---------------------+ - -In order to use the *db-migrator* tool, the system must be configured with a database. - -.. code-block:: bash - - SQL_HOST=mariadb Maven Repositories ================== The drools libraries in the PDP-D uses maven to fetch rules artifacts and software dependencies. -The default *settings.xml* file specifies the repositories to search. This configuration +The default *settings.xml* file specifies the repositories to search. This configuration can be overriden with a custom copy that would sit in a mounted configuration directory. See an example of the OOM override `settings.xml <https://github.com/onap/oom/blob/master/kubernetes/policy/components/policy-drools-pdp/resources/configmaps/settings.xml>`_. @@ -920,19 +882,6 @@ in a container. -s|--settings: custom settings.xml -a|--artifact: file artifact (jar or pom) to deploy and/or install -AAF -=== - -Policy can talk to AAF for authorization requests. To enable AAF set -the following environment variables: - -.. code-block:: bash - - AAF=true - AAF_NAMESPACE=org.onap.policy - AAF_HOST=aaf-locate.onap - -By default AAF is disabled. Policy Tool =========== @@ -969,15 +918,14 @@ It contains 3 sections: - *PDP-D* running status - *features* applied -- Data migration status on a per database basis. The *start* and *stop* commands are useful for developers testing functionality on a docker container instance. Telemetry Shell =============== -*PDP-D* offers an ample set of REST APIs to debug, introspect, and change state on a running PDP-D. This is known as the -*telemetry* API. The *telemetry* shell wraps these APIs for shell-like access using +*PDP-D* offers an ample set of REST APIs to debug, introspect, and change state on a running PDP-D. This is known as the +*telemetry* API. The *telemetry* shell wraps these APIs for shell-like access using `http-prompt <http://http-prompt.com/>`__. .. code-block:: bash @@ -1040,7 +988,6 @@ These are the configuration items that can reside externally and override the de - ***.post.sh** scripts that will be executed after the PDP-D starts. - **policy-keystore** to override the default PDP-D java keystore. - **policy-truststore** to override the default PDP-D java truststore. -- **aaf-cadi.keyfile** to override the default AAF CADI Key generated by AAF. - ***.properties** to override or add any properties file for the PDP-D, this includes *controller*, *endpoint*, *engine* or *system* configurations. - **logback*.xml** to override the default logging configuration. @@ -1109,9 +1056,6 @@ First create an environment file (in this example *env.conf*) to configure the P POLICY_PDP_PAP_API_KEY= POLICY_PDP_PAP_API_SECRET= - # DMaaP - - DMAAP_SERVERS=localhost Note that *SQL_HOST*, and *REPOSITORY* are empty, so the PDP-D does not attempt to integrate with those components. @@ -1119,18 +1063,6 @@ to integrate with those components. Configuration ~~~~~~~~~~~~~ -In order to avoid the noise in the logs that relate to dmaap configuration, a startup script (*noop.pre.sh*) is added -to convert *dmaap* endpoints to *noop* in the host directory to be mounted. - -noop.pre.sh -""""""""""" - -.. code-block:: bash - - #!/bin/bash -x - - sed -i "s/^dmaap/noop/g" $POLICY_HOME/config/*.properties - active.post.sh """""""""""""" @@ -1171,7 +1103,6 @@ To run the *telemetry shell* and other tools from the host: docker exec -it PDPD bash -c "/opt/app/policy/bin/telemetry" docker exec -it PDPD bash -c "/opt/app/policy/bin/policy status" - docker exec -it PDPD bash -c "/opt/app/policy/bin/db-migrator -s ALL -o report" Controlled instantiation of the PDP-D ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1332,23 +1263,6 @@ and the *mariadb* database: POLICY_PDP_PAP_API_KEY= POLICY_PDP_PAP_API_SECRET= - # DMaaP - - DMAAP_SERVERS=localhost - -prepare.pre.sh -~~~~~~~~~~~~~~ - -A pre-start script *config/prepare.pres.sh"can be added the custom config directory -to prepare the PDP-D to activate the distributed-locking feature (using the database) -and to use "noop" topics instead of *dmaap* topics: - -.. code-block:: bash - - #!/bin/bash - - bash -c "/opt/app/policy/bin/features enable distributed-locking" - sed -i "s/^dmaap/noop/g" $POLICY_HOME/config/*.properties active.post.sh ~~~~~~~~~~~~~~ @@ -1381,7 +1295,7 @@ The reader can also look at the `policy/docker repository <https://github.com/on More specifically, these directories have examples of other PDP-D configurations: * `plans <https://github.com/onap/policy-docker/tree/master/compose>`__: startup & teardown scripts. -* `scripts <https://github.com/onap/policy-docker/blob/master/compose>`__: docker-compose files. +* `scripts <https://github.com/onap/policy-docker/blob/master/compose/compose.yaml>`__: docker-compose file. * `tests <https://github.com/onap/policy-docker/blob/master/csit/resources/tests/drools-pdp-test.robot>`__: test plan. Configuring the PDP-D in an OOM Kubernetes installation diff --git a/docs/installation/docker.rst b/docs/installation/docker.rst index b2b45ed5..5a3baca5 100644 --- a/docs/installation/docker.rst +++ b/docs/installation/docker.rst @@ -141,10 +141,10 @@ Start the containers manually **Step 1:** Set the containers location and project. -For *local* images, set CONTAINER_LOCATION="", located at the `export-ports.sh` script +For *local* images, set `LOCAL_IMAGES=true`, located at the `get-versions.sh` script *You will need to build locally all the images using the steps in the previous section* -For *remote* images set CONTAINER_LOCATION="nexus3.onap.org:10001/" +Remote images are downloaded by default from "nexus3.onap.org:10001" **Step 2:** Set gerrit branch @@ -207,7 +207,7 @@ Before the `-jar /app/pap.jar \ ` line, add the following block: -Dcom.sun.management.jmxremote.authenticate=false \ -Dcom.sun.management.jmxremote.local.only=false \ -On `docker-compose.yml` compose file, add to the port section the mapping 5005. +On `compose.yml` file, add to the port section the mapping 5005. .. code-block:: yaml @@ -215,7 +215,6 @@ On `docker-compose.yml` compose file, add to the port section the mapping 5005. image: ${CONTAINER_LOCATION}onap/policy-pap:${POLICY_PAP_VERSION} container_name: policy-pap depends_on: - - mariadb - simulator - api hostname: policy-pap diff --git a/docs/pap/InternalPapPdp.rst b/docs/pap/InternalPapPdp.rst index 132e0df1..77395f5b 100644 --- a/docs/pap/InternalPapPdp.rst +++ b/docs/pap/InternalPapPdp.rst @@ -10,20 +10,19 @@ The Internal Policy Framework PAP-PDP API .. contents:: :depth: 3 -This page describes the API between the PAP and PDPs. The APIs in this section are implemented using `DMaaP -API <https://wiki.onap.org/display/DW/DMaaP+API>`__ messaging. The APIs in this section are used for internal -communication in the Policy Framework. The APIs are NOT supported for use by components outside the Policy Framework and -are subject to revision and change at any time. +This page describes the API between the PAP and PDPs. The APIs in this section are used for internal +communication in the Policy Framework, using Kafka as messaging system. The APIs are NOT supported for +use by components outside the Policy Framework and are subject to revision and change at any time. There are three messages on the API: 1. PDP_STATUS: PDP→PAP, used by PDPs to report to the PAP -2. PDP_UPDATE: PAP→PDP, used by the PAP to update the policies running on PDPs, triggers a PDP_STATUS message with - the result of the PDP_UPDATE operation +2. PDP_UPDATE: PAP→PDP, used by the PAP to update the policies running on PDPs, triggers a PDP_STATUS + message with the result of the PDP_UPDATE operation -3. PDP_STATE_CHANGE: PAP→PDP, used by the PAP to change the state of PDPs, triggers a PDP_STATUS message with the result - of the PDP_STATE_CHANGE operation +3. PDP_STATE_CHANGE: PAP→PDP, used by the PAP to change the state of PDPs, triggers a PDP_STATUS message + with the result of the PDP_STATE_CHANGE operation The fields in the table below are valid on API calls: @@ -57,7 +56,7 @@ policiesToBeUndeployed N/A M N/A The list of policies ->(name) O M N/A The name of a TOSCA policy running on the PDP ->policy_type O M N/A The TOSCA policy type of the policyWhen a PDP starts, it commences periodic sending of *PDP_STATUS* - messages on DMaaP. The PAP receives these messages + messages. The PAP receives these messages and acts in whatever manner is appropriate. ->policy_type_version O M N/A The version of the TOSCA policy type of the policy ->properties O M N/A The properties of the policy for the XACML, Drools, @@ -95,9 +94,9 @@ type in the implementation of this API. ================== The purpose of this API is for PDPs to provide heartbeat, status, health, and statistical information to Policy Administration. There is a single *PDP_STATUS* message on this API. PDPs send this message to the PAP using the -*POLICY_PDP_PAP* DMaaP topic. The PAP listens on this topic for messages. +*POLICY_PDP_PAP* topic. The PAP listens on this topic for messages. -When a PDP starts, it commences periodic sending of *PDP_STATUS* messages on DMaaP. The PAP receives these messages and +When a PDP starts, it commences periodic sending of *PDP_STATUS* messages. The PAP receives these messages and acts in whatever manner is appropriate. *PDP_UPDATE* and *PDP_STATE_CHANGE* operations trigger a *PDP_STATUS* message as a response. @@ -133,13 +132,6 @@ sent to the PAP in a *PDP_STATUS* message is unknown to the PAP, the PAP locks t name: xacml-23d33c2a-8715-43a8-ade5-5923fc0f185c pdpGroup: defaultGroup pdpSubgroup: xacml - statistics: - policyDeployCount: 0 - policyDeploySuccessCount: 0 - policyDeployFailCount: 0 - policyExecutedCount: 123 - policyExecutedSuccessCount: 122 - policyExecutedFailCount: 1 .. code-block:: yaml @@ -160,16 +152,6 @@ sent to the PAP in a *PDP_STATUS* message is unknown to the PAP, the PAP locks t deployment_instance_info: node_address: drools_2_pod # Other deployment instance info - statistics: - policyDeployCount: 3 - policyDeploySuccessCount: 3 - policyDeployFailCount: 0 - policyExecutedCount: 123 - policyExecutedSuccessCount: 122 - policyExecutedFailCount: 1 - policyUndeployCount: 0 - policyUndeploySuccessCount: 0 - policyUndeployFailCount: 0 response: responseTo: 52117e25-f416-45c7-a955-83ed929d557f responseStatus: SUCCESSSS @@ -191,16 +173,6 @@ sent to the PAP in a *PDP_STATUS* message is unknown to the PAP, the PAP locks t policies: - name: onap.controllloop.operational.apex.bbs.EastRegion version: 1.0.0 - statistics: - policyExecutedCount: 0 - policyExecutedSuccessCount: 0 - policyExecutedFailCount: 0 - policyDeployCount: 1 - policyDeploySuccessCount: 1 - policyDeployFailCount: 0 - policyUndeployCount: 0 - policyUndeploySuccessCount: 0 - policyUndeployFailCount: 0 response: responseTo: 679fad9b-abbf-4b9b-971c-96a8372ec8af responseStatus: SUCCESS @@ -235,20 +207,13 @@ sent to the PAP in a *PDP_STATUS* message is unknown to the PAP, the PAP locks t name: xacml-23d33c2a-8715-43a8-ade5-5923fc0f185c pdpGroup: onap.pdpgroup.Monitoring pdpSubgroup: xacml - statistics: - policyDeployCount: 0 - policyDeploySuccessCount: 0 - policyDeployFailCount: 0 - policyExecutedCount: 123 - policyExecutedSuccessCount: 122 - policyExecutedFailCount: 1 2 PDP API for PAPs ================== The purpose of this API is for the PAP to load and update policies on PDPs and to change the state of PDPs. -The PAP sends *PDP_UPDATE* and *PDP_STATE_CHANGE* messages to PDPs using the *POLICY_PAP_PDP* DMaaP topic. +The PAP sends *PDP_UPDATE* and *PDP_STATE_CHANGE* messages to PDPs using the *POLICY_PAP_PDP* topic. PDPs listen on this topic for messages. The PAP can set the scope of *PDP_STATE_CHANGE* message: diff --git a/docs/system-attributes/policy-db-migrator.rst b/docs/system-attributes/policy-db-migrator.rst index 81019efe..351f4852 100644 --- a/docs/system-attributes/policy-db-migrator.rst +++ b/docs/system-attributes/policy-db-migrator.rst @@ -53,13 +53,13 @@ These script can take up to four parameters: - upgrade/downgrade/report * - schema - -s - - policyadmin/clampacm + - schema_name * - to - -t - - 0800/0900 + - target_version (latest is 1600) * - from - -f - - 0800/0900 + - origin_version (earliest is 0800) The container also consists of several sql files which are used to upgrade/downgrade the policy database. @@ -76,7 +76,7 @@ to run and connect to the database. * - SQL_HOST - mariadb * - SQL_DB - - policyadmin/clampacm + - policyadmin clampacm etc [one or more schema separated by space] * - SQL_USER - policy_user * - SQL_PASSWORD @@ -98,7 +98,7 @@ to run and connect to the database. * - SQL_HOST - postgres * - SQL_DB - - policyadmin/clampacm + - policyadmin clampacm etc [one or more schema separated by space] * - SQL_USER - policy_user * - SQL_PASSWORD @@ -369,6 +369,6 @@ current schema version is set to 1300 and only sql scripts from later versions a .. note:: It is advisable to take a backup of your database prior to running this utility. - Please refer to the mariadb documentation on how to do this. + Please refer to the mariadb or postgres documentation on how to do this. End of Document |