1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
6 Policy Administration Point (PAP) Architecture
7 ##############################################
15 The Policy Administration Point (PAP) keeps track of PDPs, supporting the deployment of PDP groups and the deployment
16 of policies across those PDP groups. Policies are created using the Policy API, but are deployed via the PAP.
18 The PAP is stateless in a RESTful sense, using the database (persistent storage) to track PDPs and the deployment of
19 policies to those PDPs. In short, policy management on PDPs is the responsibility of PAP; management of policies by
20 any other manner is not permitted.
22 Because the PDP is the main unit of scalability in the Policy Framework, the framework is designed to allow PDPs in a
23 PDP group to arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily
24 maintained. The PAP is responsible for controlling the state across the PDPs in a PDP group. The PAP interacts with the
25 policy database and transfers policies to PDPs.
27 The unit of execution and scaling in the Policy Framework is a *PolicyImpl* entity. A *PolicyImpl* entity runs on a PDP.
28 As is explained above, a *PolicyImpl* entity is a *PolicyTypeImpl* implementation parameterized with a TOSCA *Policy*.
30 .. image:: images/PolicyImplPDPSubGroup.svg
32 In order to achieve horizontal scalability, we group the PDPs running instances of a given *PolicyImpl* entity logically
33 together into a *PDPSubGroup*. The number of PDPs in a *PDPSubGroup* can then be scaled up and down using Kubernetes. In
34 other words, all PDPs in a subgroup run the same *PolicyImpl*, that is the same policy template implementation (in
35 XACML, Drools, or APEX) with the same parameters.
37 The figure above shows the layout of *PDPGroup* and *PDPSubGroup* entities. The figure shows examples of PDP groups for
38 Control Loop and Monitoring policies on the right.
40 The health of PDPs is monitored by the PAP in order to alert operations teams managing policies. The PAP manages the life
41 cycle of policies running on PDPs.
43 The table below shows the deployment methods in which *PolicyImpl* entities can be deployed to PDP Subgroups.
45 ========== =========================================== ============================== ==================================
46 **Method** **Description** **Advantages** **Disadvantages**
47 ========== =========================================== ============================== ==================================
48 Cold The *PolicyImpl* (*PolicyTypeImpl* and No run time configuration Very restrictive, no run time
49 TOSCA *Policy*) are predeployed on the PDP. required and run time configuration of PDPs is possible.
50 PDP is fully configured and ready to administration is simple.
53 PDPs register with the PAP when they
54 start, providing the *pdpGroup* they
55 have been preconfigured with.
57 Warm The *PolicyTypeImpl* entity is predeployed The configuration, parameters, Administration and management is
58 on the PDP. A TOSCA *Policy* may be loaded and PDP group of PDPs may be required. The configuration and
59 at startup. The PDP may be configured or changed at run time by loading life cycle of the TOSCA policies
60 reconfigured with a new or updated TOSCA or updating a TOSCA *Policy* can change at run time and must be
61 *Policy* at run time. into the PDP. administered and managed.
63 PDPs register with the PAP when they start, Support TOSCA *Policy* entity
64 providing the *pdpGroup* they have been life cycle managgement is
65 predeployed with if any. The PAP may update supported, allowing features
66 the TOSCA *Policy* on a PDP at any time such as *PolicyImpl* Safe Mode
67 after registration. and *PolicyImpl* retirement.
69 Hot The *PolicyImpl* (*PolicyTypeImpl* and The policy logic, rules, Administration and management is
70 TOSCA *Policy*) are deployed at run time. configuration, parameters, and more complex. The *PolicyImpl*
71 The *PolicyImpl* (*PolicyTypeImpl* and PDP group of PDPs may be itself and its configuration and
72 TOSCA *Policy*) may be loaded at startup. changed at run time by loading life cycle as well as the life
73 The PDP may be configured or reconfigured or updating a TOSCA *Policy* cycle of the TOSCA policies can
74 with a new or updated *PolicyTypeImpl* and *PolicyTypeImpl* into the change at run time and must be
75 and/or TOSCA *Policy* at run time. PDP. administered and managed.
77 PDPs register with the PAP when they Lifecycle management of TOSCA
78 start, providing the *pdpGroup* they have *Policy* entities and
79 been preconfigured with if any. The PAP may *PolicyTypeImpl* entites is
80 update the TOSCA *Policy* and supported, allowing features
81 *PolicyTypeImpl* on a PDP at any time after such as *PolicyImpl* Safe Mode
82 registration and *PolicyImpl* retirement.
83 ========== =========================================== ============================== ==================================
88 The APIs in the subchapters below are supported by the PAP.
93 The purpose of this API is to support CRUD of PDP groups and subgroups and to support the deployment and life cycles of
94 policies on PDP sub groups and PDPs. This API is provided by the *PolicyAdministration* component (PAP) of the Policy
95 Framework, see the :ref:`ONAP Policy Framework Architecture <architecture-label>` page.
97 PDP groups and subgroups may be prefedined in the system. Predefined groups and subgroups may be modified or deleted
98 over this API. The policies running on predefined groups or subgroups as well as the instance counts and properties may
101 A PDP may be preconfigured with its PDP group, PDP subgroup, and policies. The PDP sends this information to the PAP
102 when it starts. If the PDP group, subgroup, or any policy is unknown to the PAP, the PAP locks the PDP in state PASSIVE.
104 PAP supports the operations listed in the following table, via its REST API:
107 :header: "Operation", "Description"
110 "Health check", "Queries the health of the PAP"
111 "Consolidated healthcheck", "Queries the health of all policy components"
112 "Statistics", "Queries various statistics"
113 "PDP state change", "Changes the state of all PDPs in a PDP Group"
114 "PDP Group create/update", "Creates/updates PDP Groups"
115 "PDP Group delete", "Deletes a PDP Group"
116 "PDP Group query", "Queries all PDP Groups"
117 "Deployment update", "Deploy/undeploy one or more policies in specified PdpGroups"
118 "Deploy policy", "Deploys one or more policies to the PDPs"
119 "Undeploy policy", "Undeploys a policy from the PDPs"
120 "Policy Status", "Queries the status of all policies"
121 "Policy deployment status", "Queries the status of all deployed policies"
122 "PDP statistics", "Queries the statistics of PDPs"
123 "Policy Audit", "Queries the audit records of policies"
128 PAP interacts with the PDPs via the DMaaP Message Router. The messages listed
129 in the following table are transmitted via DMaaP:
132 :header: "Message", "Direction", "Description"
135 "PDP status", "Incoming", "Registers a PDP with PAP; also sent as a periodic heart beat; also sent in response to requests from the PAP"
136 "PDP update", "Outgoing", "Assigns a PDP to a PDP Group and Subgroup; also deploys or undeploys policies from the PDP"
137 "PDP state change", "Outgoing", "Changes the state of a PDP or all PDPs within a PDP Group or Subgroup"
139 In addition, PAP generates notifications via the DMaaP Message Router when policies are successfully or unsuccessfully
140 deployed (or undeployed) from all relevant PDPs.
142 Here is a sample notification:
144 .. literalinclude:: notification/dmaap-pap-notif.json
148 2 PAP REST API Swagger
149 ======================
151 It is worth noting that we use basic authorization for access with user name and password set to *policyadmin* and
152 *zb!XztG34*, respectively.
154 For every call, the client is encouraged to insert a uuid-type *requestID* as parameter. It is helpful for tracking each
155 http transaction and facilitates debugging. More importantly, it complies with Logging requirements v1.2. If the client
156 does not provide the requestID in a call, one will be randomly generated and attached to the response header,
159 In accordance with `ONAP API Common Versioning Strategy Guidelines
160 <https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Guidelines>`_, several custom headers
161 are added in the response to each call:
164 :header: "Header", "Example value", "Description"
167 "x-latestversion", "1.0.0", "latest version of the API"
168 "x-minorversion", "0", "MINOR version of the API"
169 "x-patchversion", "0", "PATCH version of the API"
170 "x-onap-requestid", "e1763e61-9eef-4911-b952-1be1edd9812b", "described above; used for logging purposes"
172 :download:`Download Health Check PAP API Swagger <swagger/health-check-pap.json>`
174 .. swaggerv2doc:: swagger/health-check-pap.json
176 This operation performs a health check on the PAP.
178 Here is a sample response:
180 .. literalinclude:: response/health-check-pap-resp.json
183 :download:`Download Consolidated Health Check PAP API Swagger <swagger/consolidated-healthcheck-pap.json>`
185 .. swaggerv2doc:: swagger/consolidated-healthcheck-pap.json
187 This operation performs a health check of all policy components. The response
188 contains the health check result of each component. The consolidated health check
189 is reported as healthy only if all the components are healthy, otherwise the
190 "healthy" flag is marked as false.
192 Here is a sample response:
194 .. literalinclude:: response/consolidated-healthcheck-pap-resp.json
197 :download:`Download Statistics PAP API Swagger <swagger/statistics-pap.json>`
199 .. swaggerv2doc:: swagger/statistics-pap.json
201 This operation allows statistics for PDP groups, PDP subgroups, and individual PDPs to be retrieved.
204 While this API is supported, most of the statistics are not currently updated; that work has been deferred to a later
207 Here is a sample response:
209 .. literalinclude:: response/statistics-pap-resp.json
212 :download:`Download State Change PAP Swagger <swagger/state-change-pap.json>`
214 .. swaggerv2doc:: swagger/state-change-pap.json
216 The state of PDP groups is managed by this operation. PDP groups can be in states PASSIVE, TEST, SAFE, or ACTIVE. For a full
217 description of PDP group states, see the :ref:`ONAP Policy Framework Architecture <architecture-label>` page.
219 :download:`Download Group Batch PAP API Swagger <swagger/groups-batch-pap.json>`
221 .. swaggerv2doc:: swagger/groups-batch-pap.json
223 This operation allows the PDP groups and subgroups to be created and updated. Many PDP groups can be created or updated
224 in a single POST operation by specifying more than one PDP group in the POST operation body.
225 This can be used to create the PDP group by providing all the details including the supported policy types for each subgroup.
226 However, it cannot be used to update policies; that is done using one of
227 the deployment requests. Consequently, the "policies" property of this
228 request will be ignored.
229 This can also be used to update a PDP Group, but supported policy types cannot be updated during the update operation.
230 So, "policies" and "supportedPolicyTypes" properties in the request will be ignored if provided during the PDP Group update operation.
232 The "desiredInstanceCount" specifies the minimum number of PDPs of the given
233 type that should be registered with PAP. Currently, this is just used for
234 health check purposes; if the number of PDPs registered with PAP drops below
235 the given value, then PAP will return an "unhealthy" indicator if a
236 "Consolidated Health Check" is performed.
239 If a subgroup is to be deleted from a PDP Group, then the policies must be removed from
243 Policies cannot be added/updated during PDP Group create/update operations. So, if provided, they are ignored.
244 Supported policy types are defined during PDP Group creation. They cannot be updated once they are created.
245 So, supportedPolicyTypes are expected during PDP Group create, but ignored if provided during PDP Group update.
247 Here is a sample request:
249 .. literalinclude:: request/groups-batch-pap-req.json
252 :download:`Download Group Delete PAP API Swagger <swagger/group-delete-pap.json>`
254 .. swaggerv2doc:: swagger/group-delete-pap.json
256 The API also allows PDP groups to be deleted. DELETE operations are only permitted on PDP groups in PASSIVE state.
258 :download:`Download Group Query PAP API Swagger <swagger/group-query-pap.json>`
260 .. swaggerv2doc:: swagger/group-query-pap.json
262 This operation allows the PDP groups and subgroups to be listed as well as the policies that are deployed on each PDP
265 Here is a sample response:
267 .. literalinclude:: response/group-query-pap-resp.json
270 :download:`Download Deployments Batch PAP API Swagger <swagger/deployments-batch-pap.json>`
272 .. swaggerv2doc:: swagger/deployments-batch-pap.json
274 This operation allows policies to be deployed on specific PDP groups.
275 Each subgroup includes an "action" property, which is used to indicate
276 that the policies are being added (POST) to the subgroup, deleted (DELETE)
277 from the subgroup, or that the subgroup's entire set of policies is being
278 replaced (PATCH) by a new set of policies. As such, a subgroup may appear
279 more than once in a single request, one time to delete some policies and
280 another time to add new policies to the same subgroup.
282 Here is a sample request:
284 .. literalinclude:: request/deployment-batch-pap-req.json
287 Here is a sample response:
289 .. literalinclude:: response/deployment-pap-resp.json
292 :download:`Download Deploy PAP API Swagger <swagger/policy-deploy-pap.json>`
294 .. swaggerv2doc:: swagger/policy-deploy-pap.json
296 This operation allows policies to be deployed across all relevant PDP groups.
297 PAP will deploy the specified policies to all relevant subgroups. Only the
298 policies supported by a given subgroup will be deployed to that subgroup.
301 The policy version is optional. If left unspecified, then the latest version of the policy is deployed. On the other
302 hand, if it is specified, it may be an integer, or it may be a fully qualified version (e.g., "3.0.2").
303 In addition, a subgroup to which a policy is being deployed must have at
304 least one PDP instance, otherwise the request will be rejected.
306 Here is a sample request:
308 .. literalinclude:: request/policy-deploy-pap-req.json
311 Here is a sample response:
313 .. literalinclude:: response/deployment-pap-resp.json
316 :download:`Download Undeploy PAP API Swagger <swagger/policy-undeploy-pap.json>`
318 .. swaggerv2doc:: swagger/policy-undeploy-pap.json
320 This operation allows policies to be undeployed from PDP groups.
323 If the policy version is specified, then it may be an integer, or it may be a fully qualified version (e.g., "3.0.2").
324 On the other hand, if left unspecified, then the latest deployed version will be undeployed.
327 Due to current limitations, a fully qualified policy version must always be specified.
329 Here is a sample response:
331 .. literalinclude:: response/deployment-pap-resp.json
334 :download:`Download Policy Status PAP API Swagger <swagger/policy-status-pap.json>`
336 .. swaggerv2doc:: swagger/policy-status-pap.json
338 This operation allows the status of all policies that are deployed or undeployed to be listed together.
339 The result can be filtered based on pdp group name, policy name & version.
342 When a policy is successfully undeployed, it will no longer appear in the policy status response.
344 Here is a sample response:
346 .. literalinclude:: response/policy-status-pap-resp.json
349 :download:`Download Deployed Policy PAP API Swagger <swagger/deployed-policy-pap.json>`
351 .. swaggerv2doc:: swagger/deployed-policy-pap.json
353 This operation allows the deployed policies to be listed together with their respective deployment status.
354 The result can be filtered based on policy name & version.
356 Here is a sample response:
358 .. literalinclude:: response/deployed-policy-pap-resp.json
361 :download:`Download PDP Statistics PAP API Swagger <swagger/pdp-statistics-pap.json>`
363 .. swaggerv2doc:: swagger/pdp-statistics-pap.json
365 This operation allows the PDP statistics to be retrieved for all registered PDPs.
366 The result can be filtered based on PDP group, PDP subgroup & PDP instance.
367 Along with record count, start time & end time as query parameters.
369 Here is a sample response:
371 .. literalinclude:: response/pdp-statistics-pap-resp.json
374 :download:`Download Policy Audit PAP API Swagger <swagger/policy-audit-pap.json>`
376 .. swaggerv2doc:: swagger/policy-audit-pap.json
378 This operation allows the audit records of policies to be listed together.
379 The result can be filtered based on pdp group name, policy name & version.
380 Along with record count, start time & end time as query parameters.
382 Here is a sample response:
384 .. literalinclude:: response/policy-audit-pap-resp.json
390 The *PolicyAdministration* component (PAP) is initialized using a configuration file: `papParameters.yaml
391 <https://github.com/onap/policy-pap/blob/master/packages/policy-pap-tarball/src/main/resources/etc/papParameters.yaml>`_
393 The configuration file is a YAML file containing the relevant fields for configuring the REST server, Database and DMaaP connectivity and so on.
395 3.1 Disable collection of PDP Statistics
396 ========================================
398 This configuration is to inform PAP to not save the PDP statistics in the database.
400 In *papParameters.yaml*, add or change the property savePdpStatisticsInDb to false.
403 By default, if the property is not present, it will be considered as false and
404 PDP statistics will not be saved in the database.