...
3.1.5 Template-Based Policy Creation by GUI user
TBD - No Resources to work on the GUI
Another type of users who prefer to manipulate template-based policies through GUI. Thus, we call them GUI users here, without loss of generality. The sequence diagram is shown below. Basically, all such users' operations are through GUI, including reviewing/selecting existing templates and populating selected template by providing values to fill out configurable parameters in the template. The options to fill configurable parameters should be rendered by GUI. The configurable parameters here include those embedded in the template and the ones in policy metadata like "artifactId", "version" and so on. GUI backend will invoke corresponding API calls and pass in API arguments upon users' input in the GUI. It is worth noting that, in this scenario, all parameter values used to populate the template are specified in the "data" field of the payload and passed in to the API call. PAP will call maven archetype generation plugin to package a policy artifact on top of a populated template and do nexus deployment.
...
| Create PDP group | Define the parameters for the PDP group including the type of PDP |
| Update PDP group | Change the parameters of the PDP group |
| Delete PDP group | - |
| Add PDP to PDP Group | Add a PDP to the PDP group, is the PDP spun up separately or does the PAP initiate the spinning up of the PDP? |
| Update PDP in PDP group | Update parameters of the PDP in the PDP group |
| Remove PDP from PDP group | - |
- Can a PDP be in more than one PDP group??? .....I hope not!
- We'll assume a single PAP for now.
3.3 Policy Execution APIs
...
| Name | Status | Description | |||
|---|---|---|---|---|---|
| policy/parent | New in Casablanca | Parent repository containing the POM and any other information required to build all the sub-projects | policy/core | New in Casablanca||
| Core code shared among all policy repositories | policy/common | Used in Beijing Casablanca | Policy common shared modules | ||
| policy/models | New in Casablanca | This repository will hold model code agnostic to PDP engines | |||
| policy/api | Unused in Beijing Casablanca | Policy CRUD and PEP enforcement client code | |||
| policy/pap | Unused in Beijing | Policy Administration | |||
| policy/distribution | New in Casablanca | This repository will hold the SDC Service Distribution code | |||
| policy/pdp | Unused in Beijing Used in Casblanca | Common code shared between PDP engines | policy/xacml-pdp | New in Casblanca Code moved from engine repository Casablanca | The XACML PDP implementation |
| policy/drools-pdp | Used in Beijing and CasablancaCasablanca | The Drools PDP implementation | |||
| policy/apex-pdp | New in Casablanca | This repo will hold the next generation Apex PDP engine | |||
| policy/drools-applications | Used in Beijing Casablanca | APIs and helper code for accessing other ONAP components from PDPs | |||
| policy/docker | Used in Beijing Casablanca | Policy Docker support | |||
| policy/gui | Unused in BeijingCasablanca Will be used in the future | Policy Administration GUI (Front End) | |||
| policy/engine | Used in BeijingCasablanca Will be deprecated | Contains the Policy GUI, client SDK, API's and XACML PDP Engine |
Questions
- What is the relationship between policy/common and policy/core?
- Pamela Dragosh - I don't see much "common" in policy/common. I think that majority of code is for drools-pdp and should be moved. The rest can go into policy/core
- What is the relationship between policy/models and policy/api?
- Pamela Dragosh - Models are models for building policies agnostic to the PDPs. Can be used by the PAP. The API supports the code for our API.
- How does policy/pap play with policy/distribution?
- Pamela Dragosh - current thought is policy/distribution uses the API to call the policy/pap to create and push policies. This needs more thought on this flow.
5. Writing, Deploying, and Running Policies
How to create policies (how the customers use the platform) - Chenfei Gao will collect details on this regarding current problems
5.1 Writing a policy
5.2 Deploying a Policy
5.3 Running a Policy
6. The PDP SDK: Designing and Deploying your own PDP
PDP Microservice Architecture??
TODO: How to build your own PDP and/or how to extend existing PDP.
TOOD: How a PDP expresses its capabilities and configurability
6.1 Configuring the ONAP PDPs
6.2 Customizing the ONAP PDPs
6.3 Developing your own PDP
7. Summary and Conclusions
8. Terminology
...
9. References
10. Open Questions
...
- High-level Conflict Detection and Resolution tools to help identify possible conflicts
- Availability of Conflict Detection and Resolution for Policies during development and testing phases
5. 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?) policy artifact(s) |
| Policy Development | The development environment for policies |
| PolicyTemplate | A generic prototype policy that may or may not be executable. It can be stored in Nexus and support a maven archetype interface to be to generate other policy templates and/or concrete policies. They are a way to organize a common set of rules into one place for re-usability. |
| DomainPolicy | A specialization of a generic policy for application to a specific domain |
| PolicyParameters | Parameters that configure a policy for execution in a PDP group |
| Executable Policy | A policy that can be stored in Nexus and can execute on a certain type of PDP. An executable policy is a parameterized policy template or domain policy |
| Executable 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 |
...
There are a number of ways to handle upgrade/rollback and switch between active and passive modes
...