...
This document describes the ONAP Policy Framework. It lays out the architecture of the framework and specifies the APIs provided to other components that interwork with the framework. It describes the implementation of the framework, mapping out the components, software strucure, and execution ecosystem of the framework. It goes on to provide examples that illustrate how to write, deploy, and run policies of various types using the framework.
| Table of Contents |
|---|
1. Overview
The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework is the decision making component in an ONAP system. It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they closed loop, orchestration, or more traditional open loop use case implementations. The Policy Framework is the component that is the source of truth for all policy decisions.
...
2.1 Policy Design Architecture
See Pamela Dragosh's presentation from Santa Clara, especially the workflow/state diagram for policy design/test/certification
ONAP Beijing Release Developer Forum, Dec. 11-13, 2017, Santa Clara, CA US
- Model Driven Service Design that captures Policies during Design Time
...
The platform that could can policy models organically and not require any development work. The Policy GUI should be to interpret any TOSCA Model ingested and flexibly present a GUI for a user to create policies from.
Policy Model/Template/Rule Development and Orchestration - Pamela Dragosh
Policies that are expressed via natural language or a model require some development work ahead of time for them to be translated into runtime policies. Some Policy Domains will be setup and available in the platform during startup such as Control Loop Operational Policy Models, OOF placement Models, DCAE microservice models. Policy Model/Template/Rule Development is done by an experienced developer.
Policy models/templates/rules will be stored in a Nexus OSS Repository which has the ability to support all major package types and has the flexibility to be configured for various environments such as development vs production. Thus, the production environment can be configured in a strict manner to allow only artifacts being pulled from specific repositories and block other repositories. While the development environment can be separately configured so offline development/testing can be performed with or without production policies.
Model Development
Template Development
Rule Development
TODO: How does an Policy get updated? How the nexus is going to work? How does template development work?
2.2 Policy Deployment Architecture
...
- Inter-PDP protocol is the protocol that instances of any PDP type can use to communicate with each other to manage state and deployment
- Intra-PDP protocol is the protocol that instances of a particular PDP type use to communicate with each other, to manage state and deployment
- Load balancing of events towards PDP pools could be done with DMaap using the underlying Kafka consumer group mechanisms
PEP Registration and Enforcement Guidelines - Pamela Dragosh
How do we set that up?
How do we ensure the API's allow flexibility for getting policy decisions?
PDP specific? May not relevant to drools or apex?
https://ericsson.github.io/apex-docs/policy-guide/pg-policy-matrix.html
3. APIs Provided by the Policy Framework and how to use them
...
PAP to all PDPs in PDP group
| Deploy Policy | Deploy a policy artifact version taken from Nexus to all PDPs in the PDP group |
| Retire Policy | Remove a policy artifact from all PDPs in the PDP group |
| Activate Policy in Safe Mode | Activate a policy version in safe mode, no updates made to the network/system |
| Activate Policy in Live Mode | Activate a policy version running live |
| Upgrade Policy | Replace an active policy with a more recent version of the same policy |
| Rollback Policy | Replace an active policy with an older version of the same policy |
- Update of policies across PDPs in a PDP group use "eventually consistent" semantics, transactions or ACID semantics will not be supported
- Event though PDPs could listen or monitor Nexus for updates to policies, the PAP should be the component responsible for deciding if and what policy upgrades are propagated to the entire PDP group.
PDP Group Admin in PAP
| 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.
...
PAP to all PDPs in PDP group
| Modify Policy Parameters* | Change the parameters of a policy |
| Get Status | Report on the state of the policy artifacts running in the PDPs |
| Get State | Report on the execution status of the policies running on the PDPs |
- *A policy may be parameterized. There are two ways to handle this
- Combine a raw policy into a parameterized policy and deploy the parameterized policy at run time
- Have the raw policy and its parameters as separate artifacts and deploy them separately
- Do not consider the parameters as an artifact but allow them to be modified directly by users setting them using an interface towards the PAP at run time
Policy Execution (Users to PDP Group pr PDP)
| Execute policy on PDP group synchronously | Run a policy on any PDP in a PDP group and await the response |
| Execute policy on PDP group asynchronously | Run a policy on any PDP in a PDP group, fire and forget |
| Execute policy on PDP synchronously** | Run a policy on a specific PDP and await the response (Deprecate) |
| Execute policy on PDP asynchronously** | Run a policy on a specific PDP, fire and forget (Deprecate) |
- **Applications using the Policy Framework should not be aware of specific PDPs, we should only support this behaviour for existing users and deprecate this usage.
- Load Balancing across PDP group......Stateless PDPs no problem.....set up stateful transfer between PDPs if supported....Address specific PDPs
...
- Database off PAP (PDPs report back to PAP, don’t access database directly)
- Database could be replaced by/interchangeable with some ONAP persistence system (DMaaP or DCAE)?
Observations
- Policy-core has definitions of the Policy protocols and the interfaces for all the interactions between the policy components. It doesn’t have much functional code, it’s mainly the model of the system and to enforce the overall structure and interactions in the system. Some of the current engine goes in there. Implementation of the protocols is in this modules including the Inter-PDP protocol and the generic parts of the Intra-PDP protocol
- PAP functionality extended to do life cycle monitoring and run time monitoring of PDPs, moves out of engine to separate git repository. The Deployment and Monitoring could be separate modules
- Generic PDP functionality is in a separate PDP module, the current generic PDP functionality moves there and is extended to provide generic model driven PDP support for arbitrary PDPs
- PDP-X specific functionality goes to the PDP-X module
- PDP-D and BRMSGW combined in PDP-D (PDP-D related functions in engine and the current drools-pdp combined)
- The drools-applications module generalized to provide interfaces for all the Policy Framework including arbitrary PDPs towards the other ONAP components in the Policy Interactions module. This must have a mechanism to allow model-driven interactions, in other words define interfaces at run time rather than at design time in Java or JAXB.
- All persistence is In the Policy Persistence module in order to keep persistence nastiness out of the other modules, state from PDPs can be persisted by reading state over the Policy Management Protocol. The Policy Management Protocol could use Distributed Hash Maps to share state with Persistence.
- All PDP implementations specialize the generic interfaces from Policy-core and PDP and can extend the Intra-PDP protocol with PDP-specific support, for example for state and context sharing
- Not much thought gone into the Portal as yet except that it will use REST interfaces for interactions.
4.1 Policy Design Implementation
...
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
7. Terminology
...
8. 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 DevelopmentThe development environment for policies | |
| ProtoPolicy | A generic policy that may or may not be executable |
| 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 proto policy 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 |