In essence, a native policy is a custom policy/rule implementation for a specific PDP engine such as: drools DRL rules, xacml XML policies or apex JSON policies.
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 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
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
Pam
1.3 APEX JSON
APEX policy development includes three parts - develop the state machine transition using APEX language (i.e. .apex file), develop I/O event schema to each state (i.e. .avro files) and develop processing logic in each state/task (i.e. javascript files). APEX policy developer should follow best practices to develop APEX policies and submit for git review once they are done. Then APEX command line tool can be used to generate the executable JSON for PDP-A.
2. Policy Lifecycle API CRUD Enhancements
In order to designate between native policy/rule types, the REST header "Content-Type" is configured for each PDP engines specific content.
| PDP Engine | Content-Type | Description |
|---|---|---|
| PDP-D: Drools | application/vnd.onap.drools+text application/vnd.onap.drools.mvn+xml | Drools DRL text files. Question: Does Drools have a custom content-type already?? Maven XML dependency specification for a java artifact containing drools rules. Does maven have a custom content-type?? |
| PDP-X: XACML | application/xacml+xml; version=3.0 | Per http://docs.oasis-open.org/xacml/xacml-rest/v1.0/cos01/xacml-rest-v1.0-cos01.html |
| PDP-A: Apex | application/vnd.onap.apex+json | Apex JSON policy files. TBC with Apex team |
2.1 PDP-D Content-Types
chenfei
2.2 PDP-X Content-Types
pam
2.3 PDP-A Content-Types
TBA
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.
| HTTP Method | Endpoint | Content-Type | Description | Example |
|---|---|---|---|---|
| POST | /natives/{policy-id} | *see above | Creates a native policy using the given id. Returns the id and version. | 200 {
"policy-id": "id-1",
"policy-version" : "1.0.0"
}
|
| GET | /natives | application/json application/yaml | Returns a list of ID/Version of natives policies | 200 {
"policies": [
{ "policy-id" : "id-1",
"policy-version" : "1.0.0"
}
]
}
|
| GET | /natives/{policy-id} | Get a list of versions | ||
| chenfei finish |
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".
3.1 Example of PDP Register
TODO - add example register from Drools PDP. Chenfei.
show drools registration
Question: Do we need a version attached to the native content-type? Might be easier to keep it around.
3.2 Example PDP Group Deploy
{
"groups": [
{
"name": "defaultGroup",
"description": "The default group that registers all supported policy types and pdps.",
"pdpGroupState": "ACTIVE",
"properties": {},
"pdpSubgroups": [
{
"pdpType": "apex",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.operational.Apex",
"version": "1.0.0"
}
],
"supportedContentTypes": [
{
"name": "application/vnd.onap.apex+json",
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 0,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "apex_35",
"pdpState": "ACTIVE",
"healthy": "HEALTHY",
"message": "Pdp Heartbeat"
}
]
},
{
"pdpType": "drools",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.Operational",
"version": "1.0.0"
}
],
"supportedContentTypes": [
{
"name": "application/vnd.onap.drools+text",
"version": "1.0.0"
},
{
"name": "application/vnd.onap.drools.mvn+xml"
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 0,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "dev-policy-drools-0",
"pdpState": "ACTIVE",
"healthy": "HEALTHY"
}
]
},
{
"pdpType": "xacml",
"supportedPolicyTypes": [
{
"name": "onap.policies.controlloop.guard.FrequencyLimiter",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.MinMax",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.Blacklist",
"version": "1.0.0"
},
{
"name": "onap.policies.controlloop.guard.coordination.FirstBlocksSecond",
"version": "1.0.0"
},
{
"name": "onap.Monitoring",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.cdap.tca.hi.lo.app",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.dcaegen2.collectors.datafile.datafile-app-server",
"version": "1.0.0"
},
{
"name": "onap.policies.monitoring.docker.sonhandler.app",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.AffinityPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.DistancePolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.HpaPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.OptimizationPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.PciPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.QueryPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.SubscriberPolicy",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.Vim_fit",
"version": "1.0.0"
},
{
"name": "onap.policies.optimization.VnfPolicy",
"version": "1.0.0"
}
],
"supportedContentTypes": [
{
"name": "application/xacml+xml; version=3.0",
"version": "1.0.0"
}
],
"policies": [],
"currentInstanceCount": 1,
"desiredInstanceCount": 1,
"properties": {},
"pdpInstances": [
{
"instanceId": "dev-policy-policy-xacml-pdp-558c478477-g85jl",
"pdpState": "ACTIVE",
"healthy": "HEALTHY"
}
]
}
]
}
]
}
3.3 Deploy/Undeploy API
Simple vs Fully - what changes are needed if any?? Chenfei
4. PDP Changes
Each PDP will need to be able to support native policies being deploy/undeployed to it as done today.
4.1 Drools PDP
Drools PDP will need to be able to ingest a DRL directly into the controller. TBD - how to find/select the right controller. Or instantiate
4.2 XACML PDP
XACML PDP will need to be able to ingest a XACML XML directly. One suggestion is to create an application specifically for the XACML natives rules by default. The opportunity exists where a policy designer could create a specific application that supports native XACML policies (with or without TOSCA Policy Types as an option) and uses the grouping of PDPs to differentiate itself from the default XACML native rule application. The XACML PDP should also be enhanced to support configuring of applications in order to provide flexibility to the policy designers as to where all of its possible policy types and content types are deployed.
With regards to the Decision API supported by XACML, that api can be enhanced to support XACML XML requests/responses directly.
TODO: Show these scenarios Pam will do this.
4.3 Apex PDP
Apex PDP will need to be able to ingest custom Apex JSON policies. TBC with that team - may already be well-supported.