...
PolicyDevelopment creates policy artifacts and supporting information in the policy database. PolicyAdministration reads those artifacts and the supporting information from the policy database whilst deploying policy artifacts. Once the policy artifacts are deployed, PolicyAdministration handles the run-time management of the PDPs on which the policies are running. PolicyDeveloment PolicyDevelopment interacts with ONAP design time components, and has no programmatic interface with PolicyAdministration, PolicyExecution or any other run-time ONAP components.
...
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDeployment and PolicyExecution.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDevelopment and PolicyDeployment.
...
See also Sectino 2 of the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page, where the mechanisms for PDP Deployment and Registration with PAP are explained.
...
Service | Endpoint | Description |
---|---|---|
PAP | https://policy-pap | The PAP service, used for policy administration and deployment. See Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation for details of the API for this service |
PDP-X-domain | https://policy-pdpx-domain | A PDP service is defined for each PDP group. A PDP group is identified by the domain on which it operates. For example, there could be two PDP-X domains, one for admission policies for ONAP proper and another for admission policies for VNFs of operator Supacom. Two PDP-X services are defined: https://policy-pdpx-onap |
PDP-D-domain | https://policy-pdpd-domain | |
PDP-A-domain | https://policy-pdpa-domain |
...
PlantUML Macro | ||
---|---|---|
| ||
@startuml object PDPSubGroup object PDPService object PolicySet object PDP object PolicyPolicyImpl PDPSubGroup "1" -- "1" PDPService : > Lifecycle\nManaged\nBy PDPService "1" -- "*" PDP : > Manages\nLifecycle\nOf PDPService "1" -- "1" PolicySet : > Executes PolicySet "1" -- "*" PDP : > Executes\nOn PolicySet "1" -- "*" PolicyPolicyImpl : > Contains @enduml |
There is a one to one relationship between a PDP SubGroup, a Kubernetes PDP service, and the set of policies assigned to run in the PDP subgroup. Each PDP service runs a single PDP subgroup with multiple PDPs, which executes a specific Policy Set containing a number of policies that have been assigned to that PDP subgroup. Having and maintaining this principle makes policy deployment and administration much more straightforward than it would be if complex relationships between PDP services, PDP subgroups, and policy sets.
...
PlantUML Macro | ||
---|---|---|
| ||
@startuml !define table(x) class x << (T,#FFAAAA) >> !define primary_key(x) <u>x</u> hide methods hide stereotypes table(PDP_SUBGROUP) { primary_key(PDP_SUBGROUP_ID) PDP_SUBGROUP_NAME PDP_SUBGROUP_VERSION PDP_TYPE PDP_SERVICE_ENDPOINT POLICY_SET_ID PDP_SUBGROUP_STATE } table(PDP) { primary_key(PDP_ID) PDP_NAME PDP_VERSION PDP_TYPE PDP_ENDPOINT PDP_SUBGROUP_ID POLICY_SET_ID PDP_STATE } table(POLICY_SET) { primary_key(POLICY_SET_ID) POLICY_SET_NAME POLICY_SET_VERSION } table(POLICYPOLICYIMPL) { primary_key(POLICY_IMPL_ID) POLICY_NAME POLICY_VERSION PDP_TYPE POLICY_ARTIFACT } table(POLICY_SET_TO_POLICY_IMPL) { POLICY_SET_ID POLICY_IMPL_ID } PDP_SUBGROUP::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID PDP::PDP_SUBGROUP_ID --> PDP_SUBGROUP::PDP_SUBGROUP_ID PDP::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID POLICY_SET_TO_POLICY_IMPL::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID POLICY_SET_TO_POLICY_IMPL::POLICY_IDIMPLID --> POLICY::POLICY_IMPL_ID @endum |
The diagram above gives an indicative structure of the run time topology information in the Policy Framework database. Note that the PDP_SUBGROUP_STATE and PDP_STATE fields hold state information for life cycle management of PDP groups and PDPs.
...
The sequence diagram below shows the actions of the PDP at startup. See also Section 4 of the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page for the API used to implement this sequence.
...
In ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision API's. Some example PEP's are: DCAE, OOF, and SDNC.
See Section 3.4 of the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation for more information on the Decision APIs.
3. APIs Provided by the Policy Framework
See the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page.
4. Terminology
PAP (Policy Administration Point) | A component that administers and manages policies |
PDP (Policy Deployment Point) | A component that executes a policy artifact (One or many?) |
PDP_<> | A specific type of PDP |
PDP Group | A group of PDPs that execute the same set of policies |
Policy Development | The development environment for policies |
Policy Type | A generic prototype definition of a type of policy in TOSCA, see the TOSCA Policy Primer |
Policy | An executable policy defined in TOSCA and created using a Policy Type, see the TOSCA Policy Primer |
Policy Set | A set of policies that are deployed on a PDP group. One and only one Policy Set is deployed on a PDP group |
...