.. container:: paragraph
- OnapPfConfig.json is the file which contains the initial configuration to startup the ApexStarter service. The dmaap topics to be used for sending or receiving messages is also specified in the this file. Provide this file as argument while running the ApexOnapPf.
+ OnapPfConfig.json is the file which contains the initial configuration to startup the ApexStarter service. The Kafka topics to be used for sending or receiving messages is also specified in the this file. Provide this file as argument while running the ApexOnapPf.
.. container:: listingblock
.. container:: paragraph
- The ApexOnapPf service is now running, sending heartbeat messages to dmaap (which will be received by PAP) and listening for messages from PAP on the dmaap topic specified. Based on instructions from PAP, the ApexOnapPf will deploy or undeploy policies on the ApexEngine.
+ The ApexOnapPf service is now running, sending heartbeat messages to Kafka (which will be received by PAP) and listening for messages from PAP on the Kafka topic specified. Based on instructions from PAP, the ApexOnapPf will deploy or undeploy policies on the ApexEngine.
.. container:: paragraph
"supportedPolicyTypes":[{"name":"onap.policies.controlloop.operational.Apex","version":"1.0.0"}] (6)
},
"topicParameterGroup": {
- "topicSources" : [{ (7)
- "topic" : "POLICY-PDP-PAP", (8)
- "servers" : [ "message-router" ], (9)
- "topicCommInfrastructure" : "dmaap" (10)
- }],
- "topicSinks" : [{ (11)
- "topic" : "POLICY-PDP-PAP", (12)
- "servers" : [ "message-router" ], (13)
- "topicCommInfrastructure" : "dmaap" (14)
- }]
+ "topicSources": [
+ {
+ "topic": "policy-pdp-pap",
+ "servers": [
+ "kafka:9092"
+ ],
+ "useHttps": false,
+ "topicCommInfrastructure": "kafka",
+ "fetchTimeout": 15000
+ }
+ ],
+ "topicSinks": [
+ {
+ "topic": "policy-pdp-pap",
+ "servers": [
+ "kafka:9092"
+ ],
+ "useHttps": false,
+ "topicCommInfrastructure": "kafka"
+ }
+ ]
}
}
| | topic. |
+-----------------------------------+-------------------------------------------------+
| **10** | The source topic infrastructure. |
- | | For e.g. dmaap, noop, ueb |
+ | | For e.g. kafka, noop |
+-----------------------------------+-------------------------------------------------+
| **11** | List of topics' details to which |
| | messages are sent. |
| | topic. |
+-----------------------------------+-------------------------------------------------+
| **14** | The sink topic infrastructure. |
- | | For e.g. dmaap, noop, ueb |
+ | | For e.g. kafka, noop |
+-----------------------------------+-------------------------------------------------+
Consider a simple example where a policy *CDSActionPolicy* has a state *MakeCDSRequestState* which is also a final
state. The state is triggered by an event *AAIEvent*. A task called *HandleCDSActionTask* is associated with
*MakeCDSRequestState*.There are two output events expected from *MakeCDSRequestState* which are *CDSRequestEvent*
- (request event sent to CDS) and *LogEvent* (log event sent to DMaaP).
+ (request event sent to CDS) and *LogEvent* (log event sent to Kafka).
Writing an APEX policy with this example will involve the below changes.
*Command File:*
event create name=CDSRequestEvent version=0.0.1 nameSpace=org.onap.policy.apex.test source=APEX target=CDS
event parameter create name=CDSRequestEvent parName=actionIdentifiers schemaName=CDSActionIdentifiersType
..
- event create name=LogEvent version=0.0.1 nameSpace=org.onap.policy.apex.test source=APEX target=DMaaP
+ event create name=LogEvent version=0.0.1 nameSpace=org.onap.policy.apex.test source=APEX target=Kafka
event parameter create name=LogEvent parName=status schemaName=SimpleStringType
..
- Management of the deployment of policies to PDPs in an ONAP installation. *PolicyAdministration* gives each PDP group
a set of domain policies to execute.
-*PolicyAdministration* handles PDPs and policy allocation to PDPs using asynchronous messaging over DMaaP. It provides
+*PolicyAdministration* handles PDPs and policy allocation to PDPs using asynchronous messaging over Kafka. It provides
three APIs:
- a CRUD API for policy groups and subgroups
.. image:: images/MCSharedDB.svg
-2.3.8.2 DMaaP Arrangement
-"""""""""""""""""""""""""
+2.3.8.2 Kafka Communication
+"""""""""""""""""""""""""""
-As in prior releases, communication between the PAPs and PDPs still takes place via
-DMaaP. Two arrangements, described below, are supported.
-
-2.3.8.2.1 Local DMaaP
-~~~~~~~~~~~~~~~~~~~~~
-
-In this arrangement, each cluster is associated with its own, local
-DMaaP, and communication only happens between PAPs and PDPs within the same cluster.
-
-.. image:: images/MCLocalDmaap.svg
-
-The one
-limitation with this approach is that, when a PAP in cluster A deploys a policy, PAP
-is only able to inform the PDPs in the local cluster; the PDPs in the other clusters
-are not made aware of the new deployment until they generate a heartbeat, at which
-point, their local PAP will inform them of the new deployment. The same is true of
-changes made to the state of a PDP Group; changes only propagate to PDPs in other
-clusters in response to heartbeats generated by the PDPs.
-
-.. image:: images/MCLocalHB.svg
-
-2.3.8.2.2 Shared DMaaP
-~~~~~~~~~~~~~~~~~~~~~~
-
-In this arrangement, the PAPs and PDPs in all of the clusters are
-pointed to a common DMaaP. Because the PAP and PDPs all communicate via the same
-DMaaP, when a PAP deploys a policy, all PDPs are made aware, rather than having to
-wait for a heartbeat.
-
-.. image:: images/MCSharedDmaap.svg
+In prior releases, communication between the PAPs and PDPs took place via
+DMaaP. The communication now takes place over Kafka topics.
2.3.8.3 Missed Heartbeat
""""""""""""""""""""""""
To manage the removal of terminated PDPs from the DB, a record, containing a
"last-updated" timestamp, is maintained within the DB for each PDP. Whether using a
-local or shared DMaaP, any PAP receiving a message from a PDP will update the timestamp
+local or shared Kafka cluster, any PAP receiving a message from a PDP will update the timestamp
in the associated record, thus keeping the records “current”.
.. image:: images/MCSharedHB.svg
mvn spring-boot:run -Dspring-boot.run.arguments=”–server.port=8082”
+
+Models Simulators
+*****************
+
+Command Line
+------------
+
+ .. code-block:: bash
+
+ mvn -q -e clean compile exec:java -Dexec.mainClass="org.onap.policy.models.sim.pdp.PdpSimulatorMain" -Dexec.args="-c /PATH/TO/OnapPfConfig.json"
+
Apex-PDP
********
mvn spring-boot:run -Dspring-boot.run.arguments=”–server.port=8082”
-Models Simulators
-*****************
-
-Command Line
-------------
-
- .. code-block:: bash
-
- mvn -q -e clean compile exec:java -Dexec.mainClass="org.onap.policy.models.sim.pdp.PdpSimulatorMain" -Dexec.args="-c /PATH/TO/OnapPfConfig.json"
-
- .. code-block:: bash
-
- mvn -q -e clean compile exec:java -Dexec.mainClass="org.onap.policy.models.sim.dmaap.startstop.Main" -Dexec.args="-c /PATH/TO/DefaultConfig.json"
-
XACML-PDP
*********
A PDP (Policy Decision Point) is where the policy execution happens. The administrative actions such as
managing the PDPs, deploying or undeploying policies to these PDPs etc. are handled by PAP
(Policy Administration Point). Any PDP should follow certain behavior to be registered and functional in
-the Policy Framework. All the communications between PAP and PDP happen over DMaaP on topic *POLICY-PDP-PAP*.
+the Policy Framework. All the communications between PAP and PDP happen over Kafka on topic *POLICY-PDP-PAP*.
The below diagram shows how a PDP interacts with PAP.
.. image:: images/PDP_PAP.svg
A PDP should be configured to start with the below information in its startup configuration file.
- *pdpGroup* to which the PDP should belong to.
-- *DMaaP topic* 'POLICY-PDP-PAP' which should be the source and sink for communicating with PAP.
+- *Kafka topic* 'POLICY-PDP-PAP' which should be the source and sink for communicating with PAP.
**2. PDP sends PDP_STATUS (registration message)**
**4. PDP sends PDP_STATUS response to PDP_UPDATE**
-PDP on receiving the PDP_UPDATE message from the DMaaP topic, it first checks if the message is intended for the PDP.
+PDP on receiving the PDP_UPDATE message from the Kafka topic, it first checks if the message is intended for the PDP.
If so, it updates itself with the information in PDP_UPDATE message from PAP such as *pdpSubgroup*,
*pdpHeartbeatIntervalMs* and *policiesToBeDeployed* (if any). After handling the PDP_UPDATE message, the PDP sends
a response message back to PAP with the current status of the PDP along with the result of the PDP_UPDATE operation.
"drools/resources/secrets". Modify the drools chart values.yaml with
new credentials, and follow the procedures described at
:ref:`install-upgrade-policy-label` to redeploy the chart.
-
-To *disable https* for the DMaaP configuration topic, add a copy of
-`engine.properties <https://git.onap.org/policy/drools-pdp/tree/policy-management/src/main/server/config/engine.properties>`_
-with "dmaap.source.topics.PDPD-CONFIGURATION.https" set to "false", or alternatively
-create a ".pre.sh" script (see above) that edits this file before the PDP-D is
-started.
-
-To use *noop topics* for standalone testing, add a "noop.pre.sh" script under
-oom/kubernetes/policy/charts/drools/resources/configmaps/:
-
-.. code-block:: bash
-
- #!/bin/bash
- sed -i "s/^dmaap/noop/g" $POLICY_HOME/config/*.properties
-
The *PolicyAdministration* component (PAP) is initialized using a configuration file: `papParameters.yaml
<https://github.com/onap/policy-pap/blob/master/packages/policy-pap-tarball/src/main/resources/etc/papParameters.yaml>`_
-The configuration file is a YAML file containing the relevant fields for configuring the REST server, Database and DMaaP connectivity and so on.
+The configuration file is a YAML file containing the relevant fields for configuring the REST server, Database and Kafka connectivity and so on.
End of Document
Code Review / policy / parent.git / commitdiff