...
Goal: support controlled introduction of VNF's having operations performed upon themTODO: Flow diagram
Flow will be the same as current guard policy type implementation. Guard policies are created via CLAMP and deployed using PAP API. The XACML PDP returns decisions on guard decisions. The Drools PDP "frankfurt" (to be renamed "usecases") controller has the "guard" actor which makes the guard call to XACML PDP Decision API.
Pros:
- Quick and easy to build and test with .- goal is to simply re-use what is currently built in Policy/CLAMP
- Could solve the majority of the DevOps needs
Cons:
- Generate DCAE will generate a lot of events for nothing
DESIGN
TODO: List of A&AI queries for CLAMP to use. The queries used by CLAMP must match(?) the Policy Control Loop Custom Query called during runtime.
One filter per Policy
Field: generic-vnf.vnf-id
Value(s): vnf-0000-*
Constraint 
: [equal | regexp | ! equal | anyof | alloff]
- Control Loop events that will simply be ignored/retracted
- Guard actor calls from Drools/Apex may need to be enhanced to pass properties to XACML PDP to render a decision. TBD - estimated to be a small amount of work.
Do we support compound fields? AND, OR
- at this time, due to complexity we will not support compound fields.
Policy
Policy Types
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
tosca_definitions_version: tosca_simple_yaml_1_1_0
policy_types:
onap.policies.controlloop.guard.common.Filter:
derived_from: onap.policies.controlloop.guard.Common
type_version: 1.0.0
version: 1.0.0
description: Supports filtering of entity id's
properties:
filters:
type: list
description: List of filters to be applied.
required: true
entry_schema:
type: onap.datatypes.guard.filter
data_types:
onap.datatypes.guard.filter:
derived_from: tosca.nodes.Root
properties:
field:
type: string
description: |
Name of the field to perform the filter on using the A&AI
<node>.<property> syntax.
Examples:
generic-vnf.vnf-name
generic-vnf.vnf-id
generic-vnf.vnf-type
vserver.vserver-id
cloud-region.cloud-region-id
required: true
constraints:
-valid_values:
- "generic-vnf.vnf-name"
- "generic-vnf.vnf-id"
- "generic-vnf.vnf-type"
- "generic-vnf.nf-naming-code"
- "vserver.vserver-id"
- "cloud-region.cloud-region-id"
filter:
type: string
description: |
The filter value itself. Examples:
RegionOne
vFWCL*
required: true
function:
type: string
description: |
The function applied to the filter. This allows the user to
specify blacklist vs whitelist of the A&AI field. And choose
an appropriate function.
Examples:
required: true
constraints:
- valid_values:
- "string-equal"
- "string-equal-ignore-case"
- "string-regexp-match"
- "string-equal-ignore-case"
- "string-contains"
- "string-greater-than"
- "string-greater-than-or-equal"
- "string-less-than"
- "string-less-than-or-equal"
- "string-starts-with"
- "string-ends-with"
blacklist:
type: boolean
description: |
Indicates if the filter should be treated as a blacklist (true)
or whitelist (false).
required: true
default: true
policies:
-
filter.vnftype:
description: Block all these VNF Types from Control Loop actions.
type: onap.policies.controlloop.guard.common.Filter
type_version: 1.0.0
version: 1.0.0
properties:
filters:
-
field: "generic-vnf.vnf-type"
filter: "vfwl*"
function: "string-regexp-match"
blacklist: true
-
filter.vnfinstance:
description: Whitelist this specific VNF to allow Control Loop actions.
type: onap.policies.controlloop.guard.common.Filter
type_version: 1.0.0
version: 1.0.0
properties:
filters:
-
field: "generic-vnf.vnf-id"
filter: "f17face5-69cb-4c88-9e0b-7426db7edddd"
function: "string-equal"
blacklist: false
|
...
- guard calls from drools/apex PDP may need to be extended to add new properties .- TBD
CLAMP
Use of the existing yaml decoder to automatically render the UI in CLAMP should be able to handle this.
So for CLAMP, the work for this scenario will be TEST only!.
Adding Search Capability
Runtime Flow
Distribution
Instantiation
Future Solution #2 - Build a common Monitoring Policy Type for DCAE components to inherit from that captures filtering.
Each analytic would add common SDK to their analytic that enforces the filtering in each analytic.
...
- Must build the SDK and re-factor existing DCAE components to integrate the SDK and ensure it is operating.
- May become difficult to manage if we start adding multiple analytics into the flow. Highly unlikely but possible long term.
Future Solution #3 - Policy PDPs are scalable and lightweight - they could be positioned strategically in a control loop flow to capture and filter VES events going in/out of analytics
Requires PDP's to support VES events (small work?)
...