This page will capture the design of the Policy PEP Registration API and the resulting thePolicy Update Notifications on Dmaap notifications of policy updates. This work is related to the functional requirements from Control Loop subcommittee: Policy Update Notifications.
Jira Legacy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Option 1 - Don't implement the API at all
Use a well-known Dmaap topic for policy updates that any application can listen to. Look for the TOSCA Policy Type the component is interested in.
Option 2 - Implement the API to register a Dmaap topic for a specific Policy Type
...
Code Block |
---|
deployed-policies:
-
policy-type: onap.policies.monitoring.cdap.tca.hi.lo.app
policy-type-version: 1.0.0
policy-id: onap.scaleout.tca
policy-version: 2.0.0
success-count: 3
failure-count: 0
undeployed-policies:
-
policy-type: onap.policies.firewall
policy-type-version: 1.0.0
policy-id: onap.firewall.tca
policy-version: 6.0.0
success-count: 3
failure-count: 0
|
- policy-id was initial approach
- matchable filters was introduced later
- per team meeting:
- For Policy Update - need to add complexity of multiple PDP groups. How does the client know which group?
- Agree to just get the first cut done and address this later. Perhaps in G Release.
Options for Decision API calls:
Code Block |
---|
{
"ONAPName": "DCAE",
"ONAPComponent": "PolicyHandler",
"ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
"action": "configure",
"resource": {
"policy-type": "onap.policies.monitoring.cdap.tca.hi.lo.app"
}
}
{
"ONAPName": "DCAE",
"ONAPComponent": "PolicyHandler",
"ONAPInstance": "622431a4-9dea-4eae-b443-3b2164639c64",
"action": "configure",
"resource": {
"policy-id": [
"onap.scaleout.tca",
"onap.restart.tca"
]
}
}
Can also use abbrev=true to get abbreviated results:
/policy/pdpx/v1/decision?abbrev=true
|