At this time *Control Loops* are the only type of applications supported.
-*Control Loop* applications must support at least one of the following *Policy Types*:
+*Control Loop* applications must support the following *Policy Type*:
-- **onap.policies.controlloop.Operational** (Operational Policies for Legacy Control Loops)
- **onap.policies.controlloop.operational.common.Drools** (Tosca Compliant Operational Policies)
Software
Source Code repositories
~~~~~~~~~~~~~~~~~~~~~~~~
-The PDP-D Applications software resides on the `policy/drools-applications <https://git.onap.org/policy/drools-applications>`__ repository. The actor libraries introduced in the *frankfurt* release reside in
-the `policy/models repository <https://git.onap.org/policy/models>`__.
+The PDP-D Applications software resides on the
+`policy/drools-applications <https://git.onap.org/policy/drools-applications>`_ repository.
+The actor libraries introduced in the *Frankfurt* release reside in the
+`policy/models repository <https://git.onap.org/policy/models>`_.
At this time, the *control loop* application is the only application supported in ONAP.
All the application projects reside under the
-`controlloop directory <https://git.onap.org/policy/drools-applications/tree/controlloop>`__.
+`controlloop directory <https://git.onap.org/policy/drools-applications/tree/controlloop>`_.
Docker Image
~~~~~~~~~~~~
-See the *drools-applications*
-`released versions <https://wiki.onap.org/display/DW/Policy+Framework+Project%3A+Component+Versions>`__
-for the latest images:
+Check the *drools-applications* `released versions <https://github.com/onap/policy-parent/tree/master/integration/src/main/resources/release>`_
+page for the latest versions. At the time of this writing *3.0.1* is the latest version.
.. code-block:: bash
- docker pull onap/policy-pdpd-cl:1.6.4
+ docker pull nexus3.onap.org:10001/onap/policy-pdpd-cl:3.0.1
-At the time of this writing *1.6.4* is the latest version.
+At the time of this writing *3.0.1* 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.
+The *onap/policy-pdpd-cl* image extends the *onap/policy-drools* image with the *usecases*
+controller that realizes the *control loop* application.
Usecases Controller
-====================
+===================
-The `usecases <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases>`__
+The `usecases <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases>`_
controller is the *control loop* application in ONAP.
There are three parts in this controller:
-* The `drl rules <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/src/main/resources/usecases.drl>`__.
-* The `kmodule.xml <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/src/main/resources/META-INF/kmodule.xml>`__.
-* The `dependencies <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/pom.xml>`__.
+* The `drl rules <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/src/main/resources/usecases.drl>`_.
+* The `kmodule.xml <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/src/main/resources/META-INF/kmodule.xml>`_.
+* The `dependencies <https://git.onap.org/policy/drools-applications/tree/controlloop/common/controller-usecases/pom.xml>`_.
-The `kmodule.xml` specifies only one session, and declares in the *kbase* section the two operational policy types that
-it supports.
+The `kmodule.xml` specifies only one session, and declares in the *kbase* section the two
+operational policy types that it supports.
-The Usecases controller relies on the new Actor framework to interact with remote
-components, part of a control loop transaction. The reader is referred to the
-*Policy Platform Actor Development Guidelines* in the documentation for further information.
+The Usecases controller relies on the new Actor framework to interact with remote components, part
+of a control loop transaction. The reader is referred to the *Policy Platform Actor Development
+Guidelines* in the documentation for further information.
Operational Policy Types
========================
-The *usecases* controller supports the two Operational policy types:
+The *usecases* controller supports the following policy type:
-- *onap.policies.controlloop.Operational*.
- *onap.policies.controlloop.operational.common.Drools*.
-The *onap.policies.controlloop.Operational* is the legacy operational type, used before
-the *frankfurt* release. The *onap.policies.controlloop.operational.common.Drools*
-is the Tosca compliant policy type introduced in *frankfurt*.
-
-The legacy operational policy type is defined at the
-`onap.policies.controlloop.Operational.yaml <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policytypes/onap.policies.controlloop.Operational.yaml>`__.
+The *onap.policies.controlloop.operational.common.Drools* is the Tosca compliant policy type
+introduced in *Frankfurt*.
The Tosca Compliant Operational Policy Type is defined at the
-`onap.policies.controlloop.operational.common.Drools <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policytypes/onap.policies.controlloop.operational.common.Drools.yaml>`__.
+`onap.policies.controlloop.operational.common.Drools <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policytypes/onap.policies.controlloop.operational.common.Drools.yaml>`_.
+
+An example of a Tosca Compliant Operational Policy:
+`vDNS <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policies/vDNS.policy.operational.input.tosca.json>`_.
+
+Policy Chaining
+===============
+
+The *usecases* controller supports chaining of multiple operations inside a Tosca Operational
+Policy. The next operation can be chained based on the result/output from an operation.
+The possibilities available for chaining are:
+
+- *success: chain after the result of operation is success*
+- *failure: chain after the result of operation is failure due to issues with controller/actor*
+- *failure_timeout: chain after the result of operation is failure due to timeout*
+- *failure_retries: chain after the result of operation is failure after all retries*
+- *failure_exception: chain after the result of operation is failure due to exception*
+- *failure_guard: chain after the result of operation is failure due to guard not allowing the operation*
-An example of a Legacy Operational Policy can be found
-`here <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policies/vDNS.policy.operational.legacy.input.json>`__.
+An example of policy chaining for VNF:
+`vFirewall <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/vFirewall.cds.policy.operational.chaining.yaml>`_.
-An example of a Tosca Compliant Operational Policy can be found
-`here <https://git.onap.org/policy/models/tree/models-examples/src/main/resources/policies/vDNS.policy.operational.input.tosca.json>`__.
+An example of policy chaining for PNF:
+`pnf <https://github.com/onap/policy-models/blob/master/models-examples/src/main/resources/policies/pnf.cds.policy.operational.chaining.yaml>`_.
Features
========
-Since the PDP-D Control Loop Application image was created from the PDP-D Engine one (*onap/policy-drools*),
-it inherits all features and functionality.
+Since the PDP-D Control Loop Application image was created from the PDP-D Engine one
+(*onap/policy-drools*), it inherits all features and functionality.
The enabled features in the *onap/policy-pdpd-cl* image are:
- **lifecycle**: enables the lifecycle APIs.
- **controlloop-trans**: control loop transaction tracking.
- **controlloop-management**: generic controller capabilities.
-- **controlloop-usecases**: new *controller* introduced in the guilin release to realize the ONAP use cases.
+- **controlloop-usecases**: new *controller* introduced in the Guilin release to realize the ONAP
+ use cases.
-The following features are installed but disabled:
-
-- **controlloop-frankfurt**: *controller* used in the frankfurt release.
-- **controlloop-tdjam**: experimental java-only *controller* to be deprecated post guilin.
-- **controlloop-utils**: *actor* simulators.
Control Loops Transaction (controlloop-trans)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-It tracks Control Loop Transactions and Operations. These are recorded in
-the *$POLICY_LOGS/audit.log* and *$POLICY_LOGS/metrics.log*, and accessible
-through the telemetry APIs.
+It tracks Control Loop Transactions and Operations. These are recorded in the
+*$POLICY_LOGS/audit.log* and *$POLICY_LOGS/metrics.log*, and accessible through the telemetry APIs.
Control Loops Management (controlloop-management)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-It installs common control loop application resources, and provides
-telemetry API extensions. *Actor* configurations are packaged in this
-feature.
+It installs common control loop application resources, and provides telemetry API extensions.
+*Actor* configurations are packaged in this feature.
Usecases Controller (controlloop-usecases)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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.
-
-Frankfurt Controller (controlloop-frankfurt)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This is the frankfurt controller that will be deprecated after the
-guilin release.
+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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Offline Mode
============
-The default ONAP installation in *onap/policy-pdpd-cl:1.6.4* is *OFFLINE*.
-In this configuration, the *rules* artifact and the *dependencies* are all in the local
-maven repository. This requires that the maven dependencies are preloaded in the local
-repository.
+The default ONAP installation in *onap/policy-pdpd-cl:1.8.2* is *OFFLINE*. In this configuration,
+the *rules* artifact and the *dependencies* are all in the local maven repository. This requires
+that the maven dependencies are preloaded in the local repository.
An offline configuration requires two configuration items:
-- *OFFLINE* environment variable set to true (see `values.yaml <https://git.onap.org/oom/tree/kubernetes/policy/values.yaml>`__.
-- override of the default *settings.xml* (see
- `settings.xml <https://git.onap.org/oom/tree/kubernetes/policy/charts/drools/resources/configmaps/settings.xml>`__) override.
+- *OFFLINE* environment variable set to true (see `values.yaml <https://git.onap.org/oom/tree/kubernetes/policy/values.yaml>`_.
+- override of the default *settings.xml* (see `settings.xml <https://git.onap.org/oom/tree/kubernetes/policy/components/policy-drools-pdp/resources/configmaps/settings.xml>`_)
+ override.
Running the PDP-D Control Loop Application in a single container
================================================================
SQL_USER=
SQL_PASSWORD=
- # AAF
-
- AAF=false
- AAF_NAMESPACE=org.onap.policy
- AAF_HOST=aaf.api.simpledemo.onap.org
-
- # PDP-D DMaaP configuration channel
+ # PDP-D configuration channel
PDPD_CONFIGURATION_TOPIC=PDPD-CONFIGURATION
PDPD_CONFIGURATION_API_KEY=
PDP_PASSWORD=password
GUARD_DISABLED=true
- # DCAE DMaaP
+ # DCAE Topic
DCAE_TOPIC=unauthenticated.DCAE_CL_OUTPUT
DCAE_SERVERS=localhost
DCAE_CONSUMER_GROUP=dcae.policy.shared
- # Open DMaaP
-
- DMAAP_SERVERS=localhost
-
# AAI
AAI_HOST=localhost
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
"""""""""""""""
-We can enable the *controlloop-utils* and disable the *distributed-locking* feature to avoid using the database.
+We can enable the *controlloop-utils* and disable the *distributed-locking* feature to avoid using
+the database.
.. code-block:: bash
bash -c "/opt/app/policy/bin/features disable distributed-locking"
bash -c "/opt/app/policy/bin/features enable controlloop-utils"
-active.post.sh
-""""""""""""""
-
-The *active.post.sh* script makes the PDP-D active.
-
-.. code-block:: bash
-
- #!/bin/bash -x
-
- bash -c "http --verify=no -a ${TELEMETRY_USER}:${TELEMETRY_PASSWORD} PUT https://localhost:9696/policy/pdp/engine/lifecycle/state/ACTIVE"
-
Actor Properties
""""""""""""""""
-In the *guilin* release, some *actors* configurations need to be overridden to support *http* for compatibility
-with the *controlloop-utils* feature.
+In the *Guilin* release, some *actors* configurations need to be overridden to support *http* for
+compatibility with the *controlloop-utils* feature.
AAI-http-client.properties
""""""""""""""""""""""""""
To run the container in detached mode, add the *-d* flag.
-Note that we are opening the *9696* telemetry API port to the outside world, mounting the *config* host directory,
-and setting environment variables.
+.. note::
+ The *9696* telemetry API port is open to the outside world, the *config* host directory is mounted
+ as a volume and environment variables are set with an env-file option.
To open a shell into the PDP-D:
docker exec -it pdp-d bash
-Once in the container, run tools such as *telemetry*, *db-migrator*, *policy* to look at the system state:
+Once in the container, run tools such as *telemetry*, *policy* to look at the system state:
.. code-block:: bash
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 Control Loop Appplication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/events @dcae.vdns.onset.json Content-Type:'text/plain'
-This will trigger the scale out control loop transaction that will interact with the *SO*
-simulator to complete the transaction.
+This will trigger the scale out control loop transaction that will interact with the *SO* simulator
+to complete the transaction.
-Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the POLICY-CL-MGT channel.
-An entry in the *$POLICY_LOGS/audit.log* should indicate successful completion as well.
+Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the
+POLICY-CL-MGT channel. An entry in the *$POLICY_LOGS/audit.log* should indicate successful
+completion as well.
vCPE use case testing
=====================
http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/events @dcae.vcpe.onset.json Content-Type:'text/plain'
-This will spawn a vCPE control loop transaction in the PDP-D. Policy will send a *restart* message over the
-*APPC-LCM-READ* channel to APPC and wait for a response.
+This will spawn a vCPE control loop transaction in the PDP-D. Policy will send a *restart* message
+over the *APPC-LCM-READ* channel to APPC and wait for a response.
Verify that you see this message in the network.log by looking for *APPC-LCM-READ* messages.
http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-LCM-WRITE/events @appc.vcpe.success.json Content-Type:'text/plain'
-Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the *POLICY-CL-MGT* channel,
-and an entry is added to the *$POLICY_LOGS/audit.log* indicating successful completion.
+Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the
+*POLICY-CL-MGT* channel, and an entry is added to the *$POLICY_LOGS/audit.log* indicating successful
+completion.
vFirewall use case testing
-===========================
+==========================
First step is to create the *operational.modifyconfig* policy.
dcae.vfw.onset.json
-~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
.. code-block:: bash
http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/events @dcae.vfw.onset.json Content-Type:'text/plain'
-This will spawn a vFW control loop transaction in the PDP-D. Policy will send a *ModifyConfig* message over the
-*APPC-CL* channel to APPC and wait for a response. This can be seen by searching the network.log for *APPC-CL*.
+This will spawn a vFW control loop transaction in the PDP-D. Policy will send a *ModifyConfig*
+message over the *APPC-CL* channel to APPC and wait for a response. This can be seen by searching
+the network.log for *APPC-CL*.
Note the *SubRequestId* field in the *ModifyConfig* message in the *APPC-CL* topic in the network.log
-Send a simulated APPC response back to the PDP-D over the *APPC-CL* channel.
-To do this, change the *REPLACEME* text in the *appc.vcpe.success.json* with this *SubRequestId*.
+Send a simulated APPC response back to the PDP-D over the *APPC-CL* channel. To do this, change the
+*REPLACEME* text in the *appc.vcpe.success.json* with this *SubRequestId*.
appc.vcpe.success.json
~~~~~~~~~~~~~~~~~~~~~~
http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-CL/events @appc.vcpe.success.json Content-Type:'text/plain'
-Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the POLICY-CL-MGT channel,
-and an entry is added to the *$POLICY_LOGS/audit.log* indicating successful completion.
+Verify in *$POLICY_LOGS/network.log* that a *FINAL: SUCCESS* notification is sent over the
+POLICY-CL-MGT channel, and an entry is added to the *$POLICY_LOGS/audit.log* indicating successful
+completion.
Running PDP-D Control Loop Application with other components
============================================================
-The reader can also look at the `integration/csit repository <https://git.onap.org/integration/csit>`__.
+The reader can also look at the `policy/docker repository <https://github.com/onap/policy-docker/tree/master/csit>`_.
More specifically, these directories have examples of other PDP-D Control Loop configurations:
-* `plans <https://git.onap.org/integration/csit/tree/plans/policy/drools-applications>`__: startup scripts.
-* `scripts <https://git.onap.org/integration/csit/tree/scripts/policy/drools-apps/docker-compose-drools-apps.yml>`__: docker-compose and related files.
-* `plans <https://git.onap.org/integration/csit/tree/tests/policy/drools-applications>`__: test plan.
-
-Additional information
-======================
-
-For additional information, please see the
-`Drools PDP Development and Testing (In Depth) <https://wiki.onap.org/display/DW/2020+Frankfurt+Tutorials>`__ page.
-
+* `plans <https://github.com/onap/policy-docker/tree/master/compose>`_: startup & teardown scripts.
+* `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.
+End of Document
Code Review / policy / parent.git / blobdiff