New component capabilities for Frankfurt, i.e. the functional enhancements.

Frankfurt release targets the completion of the work started in Dublin to re-build the Policy Framework infrastructure. The new capabilities were to complete missing functionality that was previously in the legacy components, or was targeted to be part of the platform and was not able to be finished in Dublin:

Consolidation of Policy Health Check - China Ericsson Team

POLICY-2025: This epic covers the work to ensure all the PDP's report statistics and that both the statistics and health checks are consolidated by the PAP.Closed - Per Integration team, one single health check requested that gives status for the whole of Policy Framework components.

New API implemented in PAP : /policy/pap/v1/pdps/healthcheck

Example API result:

{
    "pdps": {
        "xacml": [
            {
                "instanceId": "CN-00000994",
                "pdpState": "ACTIVE",
                "healthy": "HEALTHY"
            }
        ],
        "drools": [
            {
                "instanceId": "CN-00000994",
                "pdpState": "ACTIVE",
                "healthy": "HEALTHY"
            }
        ],
        "apex": [
            {
                "instanceId": "CN-00000994",
                "pdpState": "ACTIVE",
                "healthy": "HEALTHY"
            }
        ]
    },
    "healthy": true,
    "api": {
        "name": "Policy API",
        "url": "http://policy-api:6969/policy/api/v1/healthcheck",
        "healthy": true,
        "code": 200,
        "message": "alive"
    },
    "distribution": {
        "name": "Policy SSD",
        "url": "http://policy-distribution:6969/healthcheck",
        "healthy": true,
        "code": 200,
        "message": "alive"
    },
    "pap": {
        "name": "Policy PAP",
        "url": "http://policy-pap:6969/policy/pap/v1/healthcheck",
        "healthy": true,
        "code": 200,
        "message": "alive"
    }
}

PDP Statistics - China Ericsson Team

POLICY-2025: This epic covers the work to ensure all the PDP's report statistics and that both the statistics and health checks are consolidated by the PAP.Closed - The same epic also covers the work for collecting various statistics of registered PDP engines and storing them in the Policy DB.

Policy models and related provider classes created for storing PDP Statistics in DB.
REST API created in PAP to fetch the PDP Statistics saved in Policy DB.
PdpStatus heartbeat messages from apex-pdp has been updated to include current statistics in every interval. Xacml-pdp & drools-pdp will be updated shortly.
PAP handlers has been updated to collect & store the statistics coming in heartbeat messages to Policy DB.

PDP Monitoring GUI - China Ericsson Team

POLICY-1751: This epic covers the work to create a GUI that collects PDP statistics for monitoring PDPs.Closed - This epic covers the work to create a GUI that polls the PDP statistics from PAP for monitoring PDP engines. This is currently work in progress.

A new UI is being developed to show

the list of PDP engines registered with PAP
the statistics of an individual PDP engine.
the cumulative statistics of a group of PDP engines.
the cumulative statistics of all PDP engines for a particular domain.

Integration of CDS As an Actor @Former user (Deleted) @Rashmi Pujar

POLICY-2087: This epic captures the work to integrate CDS as an actor in the Policy FrameworkClosed - Started in Dublin as dark code, finishing the support for this new actor to be fully available for Control Loop Operational Policies

CDS is added as an actor in Policy to take actions

Integration is done by implementing a gRPC call to CDS

Validation is done against vFirewall use case

Sample Operational Policy YAML for vFirewall usecase:

controlLoop:
  version: 2.0.0
  controlLoopName: ControlLoop-vFirewall-7e4fbe9c-d612-4ec5-bbf8-605aeabdb677
  trigger_policy: unique-policy-id-1-modifyConfig
  timeout: 60
  abatement: false
policies:
  - id: unique-policy-id-1-modifyConfig
    name: modifyconfig-cds-actor
    description:
    actor: CDS
    recipe: modify-config
    target:
      resourceID: 7e4fbe9c-d612-4ec5-bbf8-605aeabdb677
      type: VNF
    payload:
      artifact_name: vFW-CDS
      artifact_version: 1.0.0
      data: '{"active-streams":"7"}'
    retry: 0
    timeout: 30
    success: final_success
    failure: final_failure
    failure_timeout: final_failure_timeout
    failure_retries: final_failure_retries
    failure_exception: final_failure_exception
    failure_guard: final_failure_guard

REST equivalent of the gRPC request from Policy to CDS to execute a CBA:

curl -X POST \
  'http://{{ip}}:{{port}}/api/v1/execution-service/process' \
  -H 'Authorization: Basic Y2NzZGthcHBzOmNjc2RrYXBwcw==' \
  -H 'Content-Type: application/json' \
  -H 'cache-control: no-cache' \
  -d '{
    "commonHeader":{
        "subRequestId":"14384b21-8224-4055-bb9b-0469397db801",
        "requestId":"d57709fb-bbec-491d-a2a6-8a25c8097ee8",
        "originatorId":"POLICY"
    },
    "actionIdentifiers":{
        "mode":"sync",
        "blueprintName":"vFW-CDS",
        "blueprintVersion":"1.0.0",
        "actionName":"config-deploy"
    },
    "payload":{
        "config-deploy-request":{
            "resolution-key":"6128eb53-0eac-4c79-855c-ff56a7b81141",
            "config-deploy-properties":{
                "service-instance.service-instance-id":"40004db6-c51f-45b0-abab-ea4156bae422",
                "generic-vnf.vnf-id":"8d09e3bd-ae1d-4765-b26e-4a45f568a092",
                "data":{
                    "active-streams":"7"
                }
            }
        }
    }
}'

More details in RTD:
- https://docs.onap.org/en/latest/submodules/policy/parent.git/docs/development/actors/cds/cds.html

Policy Update Notifications @James Hahn

POLICY-1840: This epic covers the work to develop update notifications when deployment of policies to PDPs change.Closed - When policies are deployed/undeployed (eg new version or removal), then some ONAP components need more immediate notification. Notably, DCAE microservices need to respond quickly to policy changes. @James Hahn

When a policy has been pushed (or "unpushed") to all relevant PDPs, a notification is published to the DMaaP topic, POLICY-NOTIFICATION, a sample of which is shown below:

Policy Validation @Liam Fallon

POLICY-2027: This epic covers the work to support self serve control loops.Closed - Enhances the validation of TOSCA Policy Types and provides tools to Policy Designers. @Liam Fallon

Better support for TOSCA Data Types, Policy Types and Policies. Currently (Dublin/El Alto), policies are validated by PDPs at load time, and the Policy Framework checks that the policy type of a policy is valid and exists when it is stored over the API

In Frankfurt, we will:

Validate that the parent policy types, and referenced data types in policy types and data types exist
Return fully dereferenced policy types and data types on get requests
Vaidate consistent create and update on policy types and data types
Validate references to policy tpyes and data types prior to deletion of policy types and data types
Validate versions of policy types and policies
Validation of policies against their policy types on create and update of policies (Stretch)

See R6 Data Type, Policy Type, and Policy Referencing and Versioning for more information.

Support for Native Policies @Chenfei Gao @Ram Krishna Verma @Pamela Dragosh

POLICY-1845: This epic covers the work to integrate native PDP policy supportClosed - Some support for this in the legacy components, this work greatly enhances the ability to load PDP native policies that either execute alone or in conjunction with TOSCA Policy Types. Adds in Apex Native Policy Types in addition to XACML, Drools.

Designed TOSCA-compliant solution to create/read/update/delete(CRUD), deploy/undeploy and store native PDP policies and their artifacts
Designed native PDP policy types off which native policies executable in different PDP engines (i.e. Drools, XACML, APEX) can be created and deployed
Build a validator for the API payload provided to create native PDP policies to avoid unnecessary inconsistency between policy artifacts in the nexus and TOSCA policies in the database
Build Drools PDP (PDP-D) support for native Drools policy execution
Build XACML PDP (PDP-X) support for native XACML policy enforcement
Build APEX PDP (PDP-A) support for native APEX policy execution

Native XACML policy type

Native Drools policy type

Native APEX policy type

Optimization and Naming Policies - Better Use of the Decision API @Pamela Dragosh

POLICY-2067: This epic covers the work to upgrade optimization policy types.Closed - In working with the OOF team, we are moving some of the decision making that the legacy engine could not support into the new xacml PDP engine which supports a Decision API. Previously, OOF had to make 2 separate API calls. The addition of "matchable" attributes in the Optimization and Naming policies allow the XACML PDP to dynamically translate TOSCA policies to XACML for more fine-grained policy Decisions.

The OOF optimize uses a "best matches" algorithm on top of the XACML engine fine-grained decision in order to further refine the decision to return only the "best matching" policy given the attributes in the Decision API call.

Base Optimization Policies - including "matchable"

The OOF optimization Decision includes the ability to ask the decision to take in "context" when returning policy decisions. Eliminates one less call the OOF project had to make to the Policy Decision API to retrieve policies during runtime.

Example Decision API call Payload

TOSCA Compliant Operational and Guard Policies @Pamela Dragosh

POLICY-2118: This epic covers the work to design and support TOSCA Compliant Policy Types for the operational and guard policy models.Closed - Finishing the work started in Dublin to fully move ALL the Control Loop Policy Types into TOSCA compliance with CLAMP team. Previously our operational and guard policies used a YAML format defined a few years ago. In this effort we are translating it to be fully compliant with TOSCA and cleaning up some of the syntax.

Operational Policy Type

Much discussion for this was done in the Control Loop sub committee meetings. As captured here: Control Loop Policy Type Design Proposal#1: Simple upgrade of legacy policy types to TOSCA

Policy API Enhancements @Chenfei Gao

POLICY-2028: This epic covers the backlog for api functionality.Closed - Finished work such as added "application/yaml" as Content-Type.

Added the support of "application/yaml" as Content-Type in policy lifecycle API
Created a new simplified API for creating multiple policies in one shot
Made policy types preloading configurable in the helm charts
Added new version validation for POST API payload to constrain clients to carefully specify a reasonable version for policy or policy type
Preload default policies for ONAP components

PAP ↔ PDP Communication @Ram Krishna Verma @James Hahn

POLICY-2026: This epic covers the work to support backlog for PAP and PDP communication.Closed - Clarified PAP ↔ communication of Policy Types, Health Status, PDP Group Details, Passive vs Active modes. @Ram Krishna Verma

Mapping of kubernetes deployment to PDP Subgroup
Re-synch of PAP and PDP when the supported policy type changes
Change the PAP Group Deploy/Undeploy API to only create/update PdpGroups
Create new API to deploy/undeploy policies into PdpGroups
Handle derivation in PDP supported types

RECORDING

Recording

ONAP Wiki

2020-01-15 LF ONAP Prague DDF Policy Framework - Frankfurt Improvements