Versions Compared

Old Version 1

changes.mady.by.user Ajith Sreekumar

Saved on

compared with

New Version 2

changes.mady.by.user Ajith Sreekumar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Common changes in all policy components:

  • Upgraded all policy components to Java 11.
  • Logback file can be now loaded using OOM configmap.

If needed, logback file can be loaded as a configmap during the OOM deployment. For this, just put the logback.xml file in corresponding config directory in OOM charts.

  • TOSCA changes:
    • “tosca_definitions_version” is now “tosca_simple_yaml_1_1_0”
    • “typeVersion”-> “type_version”, int->integer etc
  • SupportedPolicyTypes now removed from pdp status message.

All PDPs now send PdpGroup in heartbeat to which they belong to. SupportedPolicyTypes are not sent anymore.


POLICY-PAP

  • Policy Update Notifications

PAP now generates notifications  via the DMaaP Message Router when policies are successfully or unsuccessfully deployed (or undeployed) from all relevant PDPs.

  • PAP API to fetch Policy deployment status

Clients will be able to poll the PAP API to find out when policies have been successfully or unsuccessfully deployed to the PDP's.

  • Removing supportedPolicyTypes from PdpStatus

PDPs are assigned to a PdpGroup based on what group is mentioned in the heartbeat. Earlier this was done based on the supportedPolicyTypes.

  • Support policy types with wild-cards, Preload wildcard supported type in PAP
  • PAP should NOT make a PDP passive if it cannot deploy a policy.

If a PDP fails to deploy one or more policies specified in a PDP-UPDATE message, PAP will undeploy those policies that failed to deploy to the PDP.  This entails removing the policies from the Pdp Group(s), issuing new PDP-UPDATE requests, and updating the notification tracking data.

Also, Re-register pdp if not found in DB during heartbeat processing.

  • Consolidated health check in PAP

PAP can report the health check for ALL the policy components now. The PDP’s health is tracked based on heartbeats, and other component’s REST API is used for healthcheck.

“healthCheckRestClientParameters” (REST parameters for API and Distribution healthcheck) are added to the startup config file in PAP.

  • PDP statistics from PAP

All PDPs send statistics data as part of heartbeat. PAP reads this and saves this data to database, and this statistics data can be accessed from the monitoring GUI.

  • PAP API for Create or Update PdpGroups

A new API is now available just for creating/updating PDP Groups. Policies cannot be added/updated during PDP Group create/update operations. There is another API for this. So, if provided in create/update group request, they are ignored. Supported policy types are defined during PDP Group creation. They cannot be updated once they are created. Refer this for details: https://github.com/onap/policy-parent/blob/master/docs/pap/pap.rst#id8

  • PAP API to deploy policies to PdpGroups

A new API is introduced to deploy policies on specific PDPGroups. Each subgroup includes an "action" property, which is used to indicate that the policies are being added (POST) to the subgroup, deleted (DELETE) from the subgroup, or that the subgroup's entire set of policies is being replaced (PATCH) by a new set of policies.


POLICY-API

  • A new simplified API to create one or more policies in one call.

This simplified API doesn’t require policy type id & policy type version to be part of the URL.

The simple URI “policy/api/v1/policies” with a POST input body takes in a ToscaServiceTemplate with the policies in it.

  • List of Preloaded policy types are made configurable

Until el-alto, the list of pre-loaded policy types are hardcoded in the code. Now, this is made configurable, and the list can be specified in the startup config file for the API component under “preloadPolicyTypes”.

  • Preload default policies for ONAP components

The ability to configure the preloading of initial default policies into the system upon startup.

  • A lot of improvements at the API code and validations corresponding to the changes in policy-models.
    • Creating same policyType/policy repeatedly without any change in request body will always be successful with 200 response
    • If there is any change in the request body, then that should be a new version. If any change is posted without a version change, then 406 error response occurs.
  • Known versioning issues are there in Policy Types handling.

https://jira.onap.org/browse/POLICY-2377 covers the versioning issues in Policy. Basically, multiple versions of a Policy Type cannot be handled in TOSCA. So, in Frankfurt, latest version of the policy type is considered. This will be further looked into in Guilin.

  • Cascaded GET of PolicyTypes and Policies
  • Fetching/GET PolicyType now returns all of the referenced/parent policyTypes and dataTypes as well.
  • Fetching/GET Policy allows specifying mode now.

By default the mode is “BARE”, which returns only the requested Policy in response.

If mode is specified as “REFERENCED”, all of the referenced/parent policyTypes and dataTypes are returned as well.

  • The /deployed API is removed from policy/api

This run time administration job to see the deployment status of a policy is now possible via PAP.

  • Changes related to design and support of TOSCA Compliant Policy Types for the operational and guard policy models.