Policy R4 Dublin Architecture Review

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:

A description of the new architecture is described here:

The ONAP Policy Framework

New or modified interfaces

  1. New Interface Policy Lifecycle API - new API that is RESTful and supports TOSCA Policy Types

    1. A brief flow has been worked by the team here: TO BE DELETED - refer to Dublin Documentation

    2. Swagger documentation is being built and the team will conform with API Versioning specifications -

      1.  api-swagger1 - 2019-03-12.pdf

  2. Legacy API - no real modifications that require any ONAP component to upgrade

    1. https://onap.readthedocs.io/en/casablanca/submodules/policy/engine.git/docs/platform/offeredapis.html

    2. New List API added - documentation updated for this.

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 Dublin Independent Versioning And Release Process Plan - has a list of our incoming and outgoing dependencies.

Consumed API from other projects

Project

API Dependency

Notes

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

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 -  TO BE DELETED - refer to Dublin Documentation

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.