This page captures scoping effort for designing the solution for Policy Filtering.
Solution #1 - Add new Filter Guard Policy Type and use in conjunction with existing Blacklist
Goal: support controlled introduction of VNF's having operations performed upon them
TODO: Flow diagram
Pros:
- Quick and easy to build and test with.
- Could solve the majority of the DevOps needs
Cons:
- 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]
Do we support compound fields? AND, OR
Policy
Policy Types
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
Runtime Flow
- guard calls from drools/apex PDP may need to be extended to add new properties.
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
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.
Pros:
- Ultimate flexibility by DevOps team to place filtering wherever they wish in the Control Loop
- Simple control loops with only a one collector and analytic can be manageable
Cons:
- 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.
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?)
Pros:
- All policy and rule enforcement stays within Policy PDP-D and PDP-X
- Flexible PAP API can move and deploy policies as needed by DevOps team
- No modification to DCAE components to enforce filtering policies