El Alto to Frankfurt changes in Policy components

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.

All PDPs can now send PdpGroup to which they belong to in the registration message. If no group name is specified, then the PDP will be assigned to defaultGroup by PAP.

SupportedPolicyTypes are not sent anymore.

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

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

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

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.

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.

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.

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

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.

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.

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”.

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

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.

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.

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

Note: If “deployPolicies” field in the startup config file is true, then only the policies are deployed using PAP endpoint.

There are minor changes in the JavaScript task logic files associated with this Rhino migration. An example for this change can be seen here: https://gerrit.onap.org/r/c/policy/apex-pdp/+/103546/2/examples/examples-onap-bbs/src/main/resources/logic/SdncResourceUpdateTask.js

There is a known issue in Rhino javascript related to the usage of JSON.stringify. This is captured in this JIRA https://jira.onap.org/browse/POLICY-2463.

Until el-alto APEX-PDP has the capability to take in only a single ToscaPolicy. When PAP sends a list of Tosca Policies in PdpUpdate, only the first one is taken and only that single Policy is deployed in APEX. This is fixed in Frankfurt. Now, APEX can deploy a list of Tosca Policies altogether into the engine.

Note: There shouldn’t be any duplicates in the deployed policies (for e.g. same input/output parameter names, or some event/task names etc).

For example, when 3 policies are deployed and one is having duplicates, say same input/task or any such concept is used in the 2^nd  and 3^rd  policy, then APEX-PDP ignores 3^rd  policy and executes only 1^st and 2^nd policies. APEX-PDP also respond back to PAP with the message saying that “only Policy 1 and 2 are deployed. Others failed due to duplicate concept”.

In APEX-PDP, context is referred by the apex concept ‘contextAlbum’. When there is no major version change in the upgraded policy to be deployed, the existing context of the currently running policy is retained. When the upgraded policy starts running, it will be having access to this context as well.

For e.g. Policy A v1.1 is currently deployed to APEX. It has a contextAlbum named HeartbeatContext and heartbeats are currently added to the HeartbeatContext based on events coming in to the policy execution. Now, when Policy Av1.2(with some other changes and same HeartbeatContext) is deployed, Policy Av1.1 is replaced by Policy A1.2 in the APEX engine, but the content in HeartbeatContext is retained for Policy A1.2.

Until el-alto, PAP assigns each PDP to a PDP group based on the supportedPolicyTypes it sends in the heartbeat. But in Frankfurt, each PDP comes up saying which PdpGroup they belong to, and this is send to PAP in the heartbeat. PAP then registers the PDP to whatever PdpGroup they said they belong to. If no group name is specified like this, then PAP assigns the PDP to defaultGroup by default. SupportedPolicyTypes are not sent to PAP by the PDP now.

In APEX-PDP, this can be specified in the startup config file(OnapPfConfig.json). "pdpGroup": "<groupName>" is added under “pdpStatusParameters” in the config file.

Apex now sends the PdpStatistics data in every heartbeat sent to PAP. PAP saves this data to database, and this statistics data can be accessed from the monitoring GUI.

Until el-alto, APEX specific policy information is placed under properties|content in ToscaPolicy. Avoid keeping under "content" and keep the information directly under properties. So, the ToscaPolicy structure will have apex specific policy information in properties|engineServiceParameters, properties|eventInputParameters, properties|eventOutputParameters.

TaskParameters can be used to pass parameters from ApexConfig to the policy logic. Consider a scenario where from CLAMP, serviceId or closedLoopId has to be passed to the policy, and this should be available to do perform some logic or action within the policy. In the CLAMP UI, while configuring APEX Policy specifying taskParameters with these will enable this.

More information about the usage of Task Parameters can be found here: https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-User-Manual.html#configure-task-parameters

In the taskLogic, taskParameters can be accessed as  executor.parameters.get("ParameterKey1"))

More information can be found here: https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-Policy-Guide.html#accessing-taskparameters

APEX-PDP now supports interaction with CDS over gRPC. Until el-alto, CDS interaction was possible over REST only. A new plugin in developed in APEX for this feature. Refer the link for more details. https://onap.readthedocs.io/en/latest/submodules/policy/parent.git/docs/apex/APEX-User-Manual.html#grpc-io

Return only an abbreviated list of policies (e.g. metadata Policy Id and Version) without the actual contents of the policies (e.g. the Properties).

Added policies for SON and PCI to support each blocking the other, with test cases and appropriate requests

The OOM deployment now supports offline mode for PDP-D by default.

This allows the users to build the docker images for drools-pdp and drools-application using their own CI pipelines if needed.

server-pool is a resilient implementation that supports redundancy within and across datacentres involving multiple PDP-Drools. Implementation involves hashing of which PDP-Drools owns which transaction and routing transactions to the appropriate PDP-Drools. By implementing as a feature, any deployment can choose to use or not use server-pool for its redundancy needs.

Policy will get flooded with potentially hundreds of ONSETs at once being picked up from DMaaP. Processing of multiple ONSETs (potentially hundreds in a batch read) of the same underlying unique network alarm severely impacts performance.

Topics are decoupled from controllers. Native policies require topics configured at installation. Topics can also be overridden or new ones added when being placed in the mounted config directory.

Corresponding changes in base.conf file in OOM which is mounted.