Policy Montreal-R13 Architecture Review

1- Project Overview

The Policy subsystem of ONAP maintains, distributes, and operates on the set of rules that underlie ONAP’s control, orchestration, and management functions.  See Policy Framework Project Proposal (5/11/17) for more information.

2- New component capabilities for Honolulu-R8

The following table lists the new functional requirements Policy is committing to support for the Honolulu Release:

The following epics are in scope for Honolulu, though are not required:

POLICY-2923: use the policy-clamp ui to manage policy typesClosed, POLICY-2921: use the policy-clamp ui to manage pdp groupsClosed, POLICY-2921: use the policy-clamp ui to manage pdp groupsClosed, and POLICY-2919: add into the policy-clamp UI the policy editor capabilitiesClosed are extensions to the REQ-478: PoC - TOSCA Defined Control Loop on Honolulu ReleaseIn Progress POC.

POLICY-2484: R8: This epic covers the work to remove the technical debt for SDNR actor interface with DCAE SON and SDNR controller.Closed , POLICY-2715: Allow underlying database to be configured: MariaDB or PostgresClosed , https://lf-onap.atlassian.net/browse/POLICY-2352 are investigative.

https://lf-onap.atlassian.net/browse/POLICY-2605 covers miscellaneous technical debt from Guilin and will be completed.

3- New or modified interfaces

The following changes will be made to the interfaces during the Honolulu release:

• Add new APIs to the PAP to query the deployment status of all PDP/policy pairs.

• Change return status from 200 to 202 in the PAP deployment APIs.

• In the health check API, include information about the availability of dependent systems (e.g., A&AI, DB, DMaaP)

These are described in the following page:   PAP REST API changes for Honolulu release.

4- If they are modified, are they backwards compatible?

The PAP API deployment changes are not backwards compatible, nevertheless it is expected minimum impact as its main consumer, CLAMP, is being migrated under the Policy components umbrella.

6- Interface naming

See ARC Policy Framework Component Description - Honolulu-R8.

7- Consumed API from other projects

See ARC Policy Framework Component Description - Honolulu-R8.

8- Published API

See ARC Policy Framework Component Description - Honolulu-R8.

9- Reference to the interfaces.

See https://docs.onap.org/projects/onap-policy-parent/en/latest/offeredapis.html.

10- What are the system limits?

No more than one PAP may be run at a time.

11- Involved use cases, architectural capabilities or functional requirements.

Policy is used in the following use cases:

• vFW

• vDNS

• vCPE

• CCVPN

• 5G

12- Listing of new or impacted models used by the project

None

13-Test plan/Testing Strategy

1. Unit Testing

   1. Continue to use junit for java tests

   2. Continue to use jest for javascript tests

2. Dev-to-Dev Testing  and

   1. Communication between Policy components will be tested via Policy-specific CSITs

   2. There are no plans for individual dev-to-dev testing with other ONAP projects.  There are no facilities within Policy to test an interface independent of a use case, nor can other systems provide "sunny-day" responses without being pre-configured.  As a result, dev-to-dev testing will take place as part of the integration testing of various use cases.  This is unchanged from previous releases.

3. Integration
   
   

   1. Integration testing will be done using the integration labs with a full OOM installation

14- Any other details that are specific to this functional enhancement or UseCase.

None