Page History

...

Taking drools rules as one example, current usecases.drl used in PDP-D is a default DRL implementation for Control Loop operational policies. It is both a TOSCA Policy Type implementation and a native drools rule implementation since it is a set of rules that directly run in the PDP-D supporting the TOSCA onap.policies.Operational Policy Type. However, some policy authors might prefer to compose their own drools rules for certain features which are partially supported by the usecases.drl such as: changing the treatment of incoming event messages, adding custom timeout logic, or adding extra processing logic. Current policy framework does not provide an interface for such policy authors to bring in their own native rules. Hence, we need to come up with a solution in Frankfurt to bridge the gap.

Taking XACML as another example, some policy authors may want to add custom guard XACML policies to achieve new guard or coordination or even classification functionalities that do not require TOSCA.

1. Native Rule Development Guidelines

1.1 Drools Native Rules

1.1.1 DRL development

use existing nexus(s) that hold the released artifacts currently supported by the runtime PDP-D engines.

develop in IDE of choice (eg Eclipse/intelliJ) to ensure it compile

1.1.2 JAR development

DRL development refers to the composition of drl file which contains one or more drools rules written in drools language. These drools rules work together to fulfill policy decision making logic required by new custom application.

Policy author should develop drl rules in IDE of choice, e.g. Eclipse/IntelliJ as well as necessary junit tests to ensure it can compile.

After drl rule development, policy author should submit composed rules for git review then deploy the new jar containing new drl rules to the existing nexus repos that hold the released artifacts currently supported by the runtime PDP-D engines.

1.1.2 Dependency JAR development

Dependency JAR development refers to the development of supportive java classes that will be used in drl rules. These dependency java classes could be the java models for I/O events and functional elements like eNodeB which may include necessary attributes of that element and operational functions/methods provided by that element, e.g. reboot. It could also be any other java class which has methods for processing input events and producing policy reactions, e.g. eventManager, operationManager. The drl rules will import these classes and use them in either condition or action part.

Dependency JAR developer should use development best practices/governance to test/deploy new and/or updated java artifacts to the nexus repo for drools PDP-D. These new java development should go through git review process and include necessary junit tests to make sure they will behave correctly as expected.

1.2 XACML XML

Use editor of choice - existing XACML github jars etc. to validate/test 

...

In order to designate between native policy/rule types, the REST header "Content-Type" is configured for each PDP engines specific content.

2.1 PDP-D Content-Types

chenfei

...

pam

2.3 PDP-A Content-Types

chenfeiTBA

2.4 Endpoint Details

The Policy Lifecycle API will need to support new endpoints that consume these PDP specific Content-Type's as well as the ability to save them to the database.

{
    "policy-id": "id-1",
    "policy-version" : "1.0.0"
}

{
  "policies": [
    { "policy-id" : "id-1",
      "policy-version" : "1.0.0"
    }
  ]
}

3. PAP Enhancements

PDP Engines must now register with the PAP the native Content-Type's they support in order for policies to be deployed by the PAP engine to the PDP's. This will require an additional parameter in the Group Deploy/Undeploy to list the supported Content-Type's for the PDP engine. The proposal is to add a field "supportedContentTypes".

...