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 Models 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 model
Overarching model that supports Policy driven DCAE microservice components used in a Control Loops. The implementation that supports this model will be developed using XACML PDP to support question/answer Policy Decisions during runtime for the DCAE Policy Handler. The implementation of this Model will be used to support dynamically generated DCAE microservice component Policy Models created during Design Time using TOSCA-Lab within SDC.
Models derived from onap.policies.Monitoring
DCAE microservice components will generate their own Policy Model using TOSCA-Lab in SDC.
onap.controlloop.Operational model
This model is used to support actor/action operational policies for control loops. There will be 2 available model implementations for this schema: 1) Existing Drools PDP to support runtime Control Loop actions taken on SO/APPC/VFC/SDNC/SDNR etc; 2) New implementation using the Apex PDP to support Control Loops.
tosca_definitions_version: tosca_simple_yaml_1_0_0 policy_types: onap.policies.controlloop.Operation: derived_from: tosca.policies.Root description: Operational Policy for Control Loops
onap.controlloop.Guard model
This model supports Control Loop guard policies for frequency limiting, blacklisting and min/max guards to help protect runtime Control Loop Actions from doing harm to the network. This model will be developed using XACML PDP to support question/answer Policy Decisions during runtime for the Drools and Apex onap.controlloop.Operational Policy Model implementations.
The base schema is defined as such:
onap.controlloop.Guard.FrequencyLimiter model
onap.controlloop.Guard.Blacklist model
onap.controlloop.Guard.MinMax model
onap.controlloop.Coordination model (STRETCH)
This domain supports Control Loop Coordination policies to assist in coordinating multiple control loops during runtime. This domain will be developed using XACML PDP to support question/answer Policy Decision during runtime for the Drools onap.controlloop.operational domain Policy Domains. NOTE: Apex is optional??
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 Lifecycle State surrounding those domains such as "Safe Mode" and Policy Retirement (Stretch goals for Dublin release).
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.
TODO: Scaling of the PDP's, show that in the list
After the PDPs have registered with the PAP: http:{url}:{port}/pap/v1/pdps GET # # PAP - how it lists existing PDP Groups and Sub Groups and the models loaded # pdp_groups: - name: Control Loop runtime group description: ONAP Control Loop Operational and Guard policies subgroups: - pdp_type: drools instances: - instance: drools_1 # K8S identifier? IP?? models: - onap.controlloop.operational - instance: drools_2 models: - onap.controlloop.operational - instance: drools-3 models: - onap.controlloop.operational - pdp_type: apex instances: - instance: apex_1 models: - onap.controlloop.operational - instance: apex_2 models: - onap.controlloop.operational - instance: apex_3 models: - onap.controlloop.operational - pdp_type: xacml instances: - instance: xacml_1 models: - onap.controlloop.guard - onap.controlloop.coordination - instance: xacml_2 models: - onap.controlloop.guard - onap.controlloop.coordination - name: DCAE policy group subgroups: - pdp_type: xacml instances: - instance: xacml_1 models: - onap.controlloop.monitoring - instance: xacml_2 models: - onap.controlloop.monitoring
I would suggest that in the subgroups we define the properties for each instance rather than explicitly defining the instances, maybe something like this:
After the PDPs have registered with the PAP: http:{url}:{port}/pap/v1/pdps GET # # PAP - how it lists existing PDP Groups and Sub Groups and the models loaded # pdp_groups: - name: Control Loop runtime group description: ONAP Control Loop Operational and Guard policies subgroups: - pdp_type: drools models: # Maven coordinates here - "onap.controlloop.operational:operational-standard" - "onap.controlloop.operational:operational-enhanced" instances: # Parameters somehow passed to K8S for scaling min_instances: 3 # The parameters below are for illustration in Dublin, may be implemented later instance_spawn_load_threshold: 70% instance_kill_load_threshold: 50% instance_geo_redundnacy: true - pdp_type: apex models: # Maven coordinates here - "onap.controlloop.operational:operational-standard" - "onap.controlloop.operational:operational-enhanced" instances: # Parameters somehow passed to K8S for scaling min_instances: 3 # The parameters below are for illustration in Dublin, may be implemented later instance_spawn_load_threshold: 80% instance_kill_load_threshold: 60% instance_geo_redundnacy: true - pdp_type: xacml models: - "onap.controlloop.guard:guard-standard" - "onap.controlloop.coordination:coordination-standard" # Parameters somehow passed to K8S for scaling min_instances: 2 # The parameters below are for illustration in Dublin, may be implemented later instance_geo_redundnacy: true - name: DCAE policy group subgroups: - pdp_type: xacml models: - "onap.controlloop.monitoring:monitoring-standard" - "onap.controlloop.monitoring:monitoring-acme-inc" # Parameters somehow passed to K8S for scaling min_instances: 2 # The parameters below are for illustration in Dublin, may be implemented later instance_geo_redundnacy: true
Policy Lifecycle API - Model query
The Policy Lifecycle API will utilize the SQL database to make GET available to applications (eg CLAMP, Integration) for determining all the available models for policy creation:
http:{url}:{port}/api/v1/models 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
PAP API - Deploying 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 Pam Notes 1. PolicyId -> appending .* inside PolicyName to get any version, getConfig 2. PolicyFilter -> copy/paste of the getConfig API. Generates JSON. Had to replicate the matching of the filters 3. every property is stringified - must "know" which need to be parsed. https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/policy-handler.git;a=blob;f=policyhandler/policy_rest.py;h=85dd914d5969529d28c2d365e392abe4ac174cf0;hb=HEAD from ALEXANDER V SHATOV to Everyone: https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/policy-handler.git;a=blob;f=policyhandler/policy_receiver.py;h=249c1f742ec19eaba46051344506d312c345ae73;hb=HEAD