Brief Project Overview (brief as it should be known)
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.
New component capabilities for Dublin, i.e. the functional enhancements.
Dublin is the start for the Policy Framework team to re-build the infrastructure in order to better support multiple PDP engines and fix many issues with policy deployment. For more specifics, please refer to these pages:
- The ONAP Policy Framework: Architectural Improvements for Dublin
- Control Loop Operation and Improvements. - NOTE this improvement will also be integrated with the existing architecture and available to Control Loop applications using the old API in Dublin.
- Current API Limitations with Respect to DCAE mS Policies - WIP to help future teams to map new API's to the old API's
A description of the new architecture is described here:
New or modified interfaces
- New Interface Policy Lifecycle API - new API that is RESTful and supports TOSCA Policy Types
- A brief flow has been worked by the team here: Policy Design and API Flow for Model Driven Control Loop - Draft
- Swagger documentation is being built and the team will conform with API Versioning specifications
- Legacy API - no real modifications that require ONAP to upgrade
If they are modified, are the backwards compatible?
With regard for the new Policy Lifecycle API - the design of the Old API prohibits any backward compatibility and isn't feasible. The legacy API is still available for applications that still use it for the next few releases until it can be safely deprecated.
However, the Policy Lifecycle API will support in Dublin the Casablanca non-TOSCA policy models for Control Loop operational policies and guard policies for the CLAMP project.
Interface naming (point to an example)
The Policy R4 Casablanca Independent Versioning And Release Process Plan - has a list of our incoming and outgoing dependencies.
Consumed API from other projects
Project | API Dependency | Notes |
|---|---|---|
| Portal | 2.4.0 | |
| AAF | v2.1.2 | |
| Dmaap | v1.1.8 | |
| SDC | 1.3.0 | |
| AAI | 1.0.1 - being investigated | v16 schema NOTE: work whether to direct link to A&AI libraries or retain the current codebase and enhance for custom query work. |
| APP-C | Dmaap LCM API | No direct link to any libraries |
| SO | REST - No direct link to any libraries | |
| VFC | REST - No direct link to any libraries | |
| SDNR | Dmaap - No direct link to any libraries | |
| SDNC | REST - No direct link to any libraries |
Published API - These projects use the policy libraries to build their code
Project | API | Notes |
|---|---|---|
| CLAMP | Policy Lifecycle API | implemented in own java code |
| OOF | Legacy Policy API | implemented in own python code |
| SDNC | Legacy Policy API | implemented in own code |
| DCAE | Policy Lifecycle API | Implemented own python code |
Reference to the interfaces.
Policy Lifecycle API - Policy Design and API Flow for Model Driven Control Loop - Draft
Legacy API: Policy API
What are the system limits?
4Gb Memory - for most of the components.
Team will be trying to minimize the footprint in Dublin by using Alpine and the re-build of the components should address unreasonable memory requirements.
Involved use cases, architectural capabilities or functional requirements.
vFW, Scale Out, vCPE, CCVPN and BBS are targeted for support.
Model driven Control Loop Design via the Control Loop Sub Committee
Listing of new or impacted models used by the project (for information only).
New Policy Type models for Control Loops is being built for Dublin. These are simply ports from existing non-TOSCA compliant models towards TOSCA compliance and a step towards integration with SDC design time. The first models are for DCAE uS Policy Models.
Will be working with the Modeling Sub Committee to hand over the models for integration with other ONAP Data and Information Models.