This page is intended to establish how the Policy Design and API Flow to/from the PAP and PDP's will work to support Model Driven Control Loops in Dublin.
Policy Design
The following Policy domains will be developed to support ONAP Model Driven Control Loops in Dublin: onap.policies.monitoring, onap.policies.controlloop.operational, onap.policies.controlloop.guard and onap.policies.controlloop.coordination.
onap.policies.monitoring domain
Overarching domain that supports Policy driven DCAE microservice components used in a Control Loop. This domain will be developed using XACML PDP to support question/answer Policy Decisions during runtime. This overarching domain is used to support dynamically generated DCAE microservice component Policy Models.
Policy Designer will create a domain application to support the concrete models and policies for DCAE microservice components.
This domain will dynamically support DCAE microservice components Policy Models that derive from TOSCA
onap.controlloop.operational domain
onap.controlloop.guard domain
onap.controlloop.coordination domain
PDP Deployment and registration with PAP
PDP's are deployed pre-packaged with their domains and will register those domains with the PAP when they are deployed via K8S.
The PAP will store any new PDP's and their domains in a SQL database in order to support state surrounding those domains.
The health of those PDP's will be updated constantly by the PAP in order to alert ops teams monitoring policy, and to ensure the Policy Lifecycle API can create policies in those domains.
Policy Lifecycle API - Domain query
The Policy Lifecycle API will utilize the SQL database to make GET available to applications (eg CLAMP, Integration) for determining all the available domains for policy creation:
http:{url}:{port}/api/v1/domains GET { "policy_domains": [ { "domain": "onap.monitoring", "id": "dublin.monitoring.base", "description": "This is the base domain that is used to help generate monitoring\ndomains for specific DCAE microservice models.\n", "pdp_types": [ "xacml" ], "version": 1 }, { "domain": "onap.controlloop.operational", "id": "dublin.operational.drools", "description": "This is the operational policy domain that support action policies for\ncontrol loops that are supported by the Drools PDP engine.\n", "pdp_types": [ "drools" ], "version": 1 }, { "domain": "onap.controlloop.operational", "id": "dublin.operational.apex", "description": "This is the operational policy domain that support action policies for\ncontrol loops that are supported by the Apex PDP engine.\n", "pdp_types": [ "apex" ], "version": 1 }, { "domain": "onap.controlloop.guard", "id": "dublin.guard", "description": "This is the XACML based guard policy domain that supports frequency limiter, blacklist/whitelist and min/max guard policies.\n", "pdp_types": [ "xacml" ], "version": 1 }, { "domain": "onap.controlloop.coordination", "id": "dublin.coordination", "description": "This is the XACML based guard policy domain that supports frequency limiter, blacklist/whitelist and min/max guard policies.\n", "pdp_types": [ "xacml" ], "version": 1 } ] }
Policy Lifecycle API - Adding new DCAE microservice component domains
For Dublin, the DCAE microservice component developer will use TOSCA-LAB to generate a specific yaml for their microservice component. These can be now loaded into the policy framework using the Policy Lifecycle API using the onap.monitoring domain. TOSCA-LAB produces the following example yaml:
Once this call is made, now the models query will display the following available models for policy creation, notice the new "onap.policy.monitoring.cdap.tca.hi.lo.app" domain listed.
http:{url}:{port}/api/v1/domains GET { "policy_domains": [ { "domain": "onap.monitoring", "id": "dublin.monitoring.base", "description": "This is the base domain that is used to help generate monitoring\ndomains for specific DCAE microservice models.\n", "pdp_types": [ "xacml" ], "version": 1 }, { "domain": "onap.controlloop.operational", "id": "dublin.operational.drools", "description": "This is the operational policy domain that support action policies for\ncontrol loops that are supported by the Drools PDP engine.\n", "pdp_types": [ "drools" ], "version": 1 }, { "domain": "onap.controlloop.operational", "id": "dublin.operational.apex", "description": "This is the operational policy domain that support action policies for\ncontrol loops that are supported by the Apex PDP engine.\n", "pdp_types": [ "apex" ], "version": 1 }, { "domain": "onap.controlloop.guard", "id": "dublin.guard", "description": "This is the XACML based guard policy domain that supports frequency limiter, blacklist/whitelist and min/max guard policies.\n", "pdp_types": [ "xacml" ], "version": 1 }, { "domain": "onap.controlloop.coordination", "id": "dublin.coordination", "description": "This is the XACML based guard policy domain that supports frequency limiter, blacklist/whitelist and min/max guard policies.\n", "pdp_types": [ "xacml" ], "version": 1 }, { "domain": "onap.policy.monitoring.cdap.tca.hi.lo.app", "id": "dublin.tca", "description": null, "pdp_types": [ "xacml" ], "version": 1 } ] }
Now that domain is available to CLAMP for creating concrete policies creation.
Policy Lifecycle API - Creating Monitoring Policies
http:{url}:{port}/api/v1/domains?domain=onap.policy.monitoring.cdap.tca.hi.lo.app&id=dublin.tca PUT Using the payload in the previous code code specified exactly to the desired values. Return payload: PolicyId: UniqueId_1 PolicyVersion: 1 Should be able to GET http:{url}:{port}/api/v1/domains/onap.policy.monitoring.cdap.tca.hi.lo.app/dublin.tca?PolicyId=UniqueId_1&PolicyVersion=1
Policy Lifecycle API - Creating Operational Policies
Policy Lifecycle API - Creating Guard Policies
Policy Lifecycle API - Creating Coordination Policies
Policy Decision API - Getting Policy Decisions
Policy decisions are required by ONAP components to support the policy-driven ONAP architecture. Currently implemented using the XACML PDP.
http:{url}:{port}/decision/v1/ POST domain=onap.policy.monitoring.cdap.tca.hi.lo.app