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 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 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
use development best practices/governance to test/deploy new and/or updated java artifacts to the nexus repo for drools PDP-D.
1.2 XACML XML
Use editor of choice - existing XACML github jars etc. to validate/test
Pam
1.3 APEX JSON
Use Apex command line tool to build the JSON.
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
chenfei
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.