diff options
Diffstat (limited to 'docs/pap/pap.rst')
| -rw-r--r-- | docs/pap/pap.rst | 139 |
1 files changed, 110 insertions, 29 deletions
diff --git a/docs/pap/pap.rst b/docs/pap/pap.rst index bca9334f..21b5b42b 100644 --- a/docs/pap/pap.rst +++ b/docs/pap/pap.rst @@ -9,29 +9,78 @@ Policy Administration Point (PAP) Architecture .. contents:: :depth: 3 -The PAP keeps track of PDPs, supporting the deployment of PDP groups and the deployment of a *policy set* across those -PDP groups. Policies are created using the Policy API, but are deployed via the PAP. +.. toctree:: + InternalPapPdp.rst -A PAP is stateless in a RESTful sense, using the database (persistent storage) to track PDPs and the deployment of -policies to those PDPs. In short, policy management on PDPs is the responsibility of PAPs; management of policy sets or -policies by any other manner is not permitted. +The Policy Administration Point (PAP) keeps track of PDPs, supporting the deployment of PDP groups and the deployment +of policies across those PDP groups. Policies are created using the Policy API, but are deployed via the PAP. + +The PAP is stateless in a RESTful sense, using the database (persistent storage) to track PDPs and the deployment of +policies to those PDPs. In short, policy management on PDPs is the responsibility of PAP; management of policies by +any other manner is not permitted. Because the PDP is the main unit of scalability in the Policy Framework, the framework is designed to allow PDPs in a PDP group to arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily maintained. The PAP is responsible for controlling the state across the PDPs in a PDP group. The PAP interacts with the -Policy database and transfers policy sets to PDPs. - -There are a number of rules for PDP group and PDP state management: - -1. Only one version of a PDP group may be ACTIVE at any time - -2. If a PDP group with a certain version is ACTIVE and a later version of the same PDP group is activated, then the - system upgrades the PDP group - -3. If a PDP group with a certain version is ACTIVE and an earlier version of the same PDP group is activated, then the - system downgrades the PDP group - -4. There is no restriction on the number of PASSIVE versions of a PDP group that can exist in the system +policy database and transfers policies to PDPs. + +The unit of execution and scaling in the Policy Framework is a *PolicyImpl* entity. A *PolicyImpl* entity runs on a PDP. +As is explained above, a *PolicyImpl* entity is a *PolicyTypeImpl* implementation parameterized with a TOSCA *Policy*. + +.. image:: images/PolicyImplPDPSubGroup.svg + +In order to achieve horizontal scalability, we group the PDPs running instances of a given *PolicyImpl* entity logically +together into a *PDPSubGroup*. The number of PDPs in a *PDPSubGroup* can then be scaled up and down using Kubernetes. In +other words, all PDPs in a subgroup run the same *PolicyImpl*, that is the same policy template implementation (in +XACML, Drools, or APEX) with the same parameters. + +The figure above shows the layout of *PDPGroup* and *PDPSubGroup* entities. The figure shows examples of PDP groups for +Control Loop and Monitoring policies on the right. + +The health of PDPs is monitored by the PAP in order to alert operations teams managing policies. The PAP manages the life +cycle of policies running on PDPs. + +The table below shows the deployment methods in which *PolicyImpl* entities can be deployed to PDP Subgroups. + +========== =========================================== ============================== ================================== +**Method** **Description** **Advantages** **Disadvantages** +========== =========================================== ============================== ================================== +Cold The *PolicyImpl* (*PolicyTypeImpl* and No run time configuration Very restrictive, no run time + TOSCA *Policy*) are predeployed on the PDP. required and run time configuration of PDPs is possible. + PDP is fully configured and ready to administration is simple. + execute when started. + + PDPs register with the PAP when they + start, providing the *pdpGroup* they + have been preconfigured with. + +Warm The *PolicyTypeImpl* entity is predeployed The configuration, parameters, Administration and management is + on the PDP. A TOSCA *Policy* may be loaded and PDP group of PDPs may be required. The configuration and + at startup. The PDP may be configured or changed at run time by loading life cycle of the TOSCA policies + reconfigured with a new or updated TOSCA or updating a TOSCA *Policy* can change at run time and must be + *Policy* at run time. into the PDP. administered and managed. + + PDPs register with the PAP when they start, Support TOSCA *Policy* entity + providing the *pdpGroup* they have been life cycle managgement is + predeployed with if any. The PAP may update supported, allowing features + the TOSCA *Policy* on a PDP at any time such as *PolicyImpl* Safe Mode + after registration. and *PolicyImpl* retirement. + +Hot The *PolicyImpl* (*PolicyTypeImpl* and The policy logic, rules, Administration and management is + TOSCA *Policy*) are deployed at run time. configuration, parameters, and more complex. The *PolicyImpl* + The *PolicyImpl* (*PolicyTypeImpl* and PDP group of PDPs may be itself and its configuration and + TOSCA *Policy*) may be loaded at startup. changed at run time by loading life cycle as well as the life + The PDP may be configured or reconfigured or updating a TOSCA *Policy* cycle of the TOSCA policies can + with a new or updated *PolicyTypeImpl* and *PolicyTypeImpl* into the change at run time and must be + and/or TOSCA *Policy* at run time. PDP. administered and managed. + + PDPs register with the PAP when they Lifecycle management of TOSCA + start, providing the *pdpGroup* they have *Policy* entities and + been preconfigured with if any. The PAP may *PolicyTypeImpl* entites is + update the TOSCA *Policy* and supported, allowing features + *PolicyTypeImpl* on a PDP at any time after such as *PolicyImpl* Safe Mode + registration and *PolicyImpl* retirement. +========== =========================================== ============================== ================================== 1 APIs @@ -59,13 +108,17 @@ PAP supports the operations listed in the following table, via its REST API: :widths: 25,70 "Health check", "Queries the health of the PAP" + "Consolidated healthcheck", "Queries the health of all policy components" "Statistics", "Queries various statistics" "PDP state change", "Changes the state of all PDPs in a PDP Group" "PDP Group create/update", "Creates/updates PDP Groups" "PDP Group delete", "Deletes a PDP Group" "PDP Group query", "Queries all PDP Groups" + "Deployment update", "Deploy/undeploy one or more policies in specified PdpGroups" "Deploy policy", "Deploys one or more policies to the PDPs" "Undeploy policy", "Undeploys a policy from the PDPs" + "Policy deployment status", "Queries the status of all deployed policies" + "PDP statistics", "Queries the statistics of PDPs" 1.2 DMaaP API ------------- @@ -124,6 +177,18 @@ Here is a sample response: .. literalinclude:: response/health-check-pap-resp.json :language: json +.. swaggerv2doc:: swagger/consolidated-healthcheck-pap.json + +This operation performs a health check of all policy components. The response +contains the health check result of each component. The consolidated health check +is reported as healthy only if all the components are healthy, otherwise the +"healthy" flag is marked as false. + +Here is a sample response: + +.. literalinclude:: response/consolidated-healthcheck-pap-resp.json + :language: json + .. swaggerv2doc:: swagger/statistics-pap.json This operation allows statistics for PDP groups, PDP subgroups, and individual PDPs to be retrieved. @@ -223,20 +288,36 @@ This operation allows policies to be undeployed from PDP groups. .. note:: Due to current limitations, a fully qualified policy version must always be specified. - -3 Future Features -================= -3.1 Order Health Check on PDPs -============================== +.. swaggerv2doc:: swagger/deployed-policy-pap.json -This operation will allow a PDP group health check to be ordered on PDP groups and on individual PDPs. The operation -will return a HTTP status code of *202: Accepted* if the health check request has been accepted by the PAP. The PAP will -then order execution of the health check on the PDPs. +This operation allows the deployed policies to be listed together with their respective deployment status. +The result can be filtered based on policy name & version. + +Here is a sample response: + +.. literalinclude:: response/deployed-policy-pap-resp.json + :language: json + +.. swaggerv2doc:: swagger/pdp-statistics-pap.json + +This operation allows the PDP statistics to be retrieved for all registered PDPs. +The result can be filtered based on PDP group, PDP subgroup & PDP instance. + +Here is a sample response: + +.. literalinclude:: response/pdp-statistics-pap-resp.json + :language: json + + +3 Future Features +================= -As health checks may be long lived operations, Health checks will be scheduled for execution by this operation. Users -will check the result of a health check test by issuing a PDP Group Query operation and checking the *healthy* field of -PDPs. +3.1 Disable policies in PDP +=========================== +This operation will allow disabling individual policies running in PDP engine. It is mainly beneficial +in scenarios where network operators/administrators want to disable a particular policy in PDP engine +for a period of time due to a failure in the system or for scheduled maintenance. End of Document |