Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

...

  • at this time, due to complexity we will not support compound fields.

Policy

Policy

...

Type

Code Block
languagejs
titleGuard Filter Policy Type and Sample Policies
linenumberstrue
collapsetrue
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
      name: onap.policies.controlloop.guard.common.Filter
      description: Supports filtering of entity id's
        properties:A&AI entities such as vnf-id, type, service, geographic region, etc.
      properties:
      filters:
   algorithm:
             type: liststring
            description: Designates the algorithm description: List of filtersblacklist-overrides to be applied.vs whitelist-overrides
                required: true
                entry_schema:default: blacklist-overrides
                    type: onap.datatypes.guard.filter
data_types:
constraints:
     onap.datatypes.guard.filter:
       - derivedvalid_fromvalues: tosca.nodes.Root
        properties:["blacklist-overrides", "whitelist-overrides"]
            fieldfilters:
                type: stringlist
                description: |
                    Name of the fieldList of filters to perform the filter on using the A&AIbe applied.
                    <node>.<property> syntax.required: true
                    entry_schema:
                    Examplestype: onap.datatypes.guard.filter
data_types:
                    generic-vnf.vnf-nameonap.datatypes.guard.filter:
                    generic-vnf.vnf-idderived_from: tosca.nodes.Root
      properties:
              generic-vnf.vnf-typefield:
            type: string
       vserver.vserver-id
     description: Name of the field to perform the filter on using the A&AI   cloud-region.cloud-region-id
  <node>.<property> syntax.
              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:
For                    RegionOne
                    vFWCL*
    example, "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.block.region.allow.one.vnf:
            description: Block all these VNF Typesthis region from Control Loop actions.
   , but allow a specific vnf.
         type: onap.policies.controlloop.guard.common.Filter
            type_version: 1.0.0
            version: 1.0.0
         properties:
   properties:
         actor: SO
        filters:
    operation: VF Module Create
            algorithm: whitelist-overrides
            filters:
            -  field: "genericcloud-vnfregion.vnf-type"
cloud-region-id
               filter: RegionOne
               filterfunction: "vfwl*"string-equal
               blacklist: true
        function    -  field: "string-regexp-match"
generic-vnf.vnf-id
               filter: e6130d03-56f1-4b0a-9a1d-e1b2ebc30e0e
               blacklistfunction: truestring-equal
    -
           filter.vnfinstanceblacklist: false
   -  filter.allow.region.block.one.vnf:
         description: Whitelistallow this specificregion VNF to allowdo Control Loop actions.
, but block a specific vnf.
         type: onap.policies.controlloop.guard.common.Filter
            type_version: 1.0.0
            version: 1.0.0
            properties:
            actor: SO
   filters:
         operation: VF Module Create
            algorithm: blacklist-overrides
            filters:
            -  field: "genericcloud-vnfregion.vnfcloud-region-id"
               filter: RegionTwo
               filterfunction: "f17face5-69cb-4c88-9e0b-7426db7edddd"
string-equal
               blacklist: false
            -  field: generic-vnf.vnf-id
               functionfilter: "string-equal"
f17face5-69cb-4c88-9e0b-7426db7edddd
               function: string-equal
               blacklist: false




true


Because of the difficulty for the application to determine "intent", the field "algorithm" is provided to allow the user to specify whether blacklist or whitelist overrides should be applied. The intent being to provide filter(s) that 

  • whitelist-overrides
    • Thus, if a policy designer writes a filter that "whitelists" a specific VNF, then that filter overrides any additional "blacklist" filter policy that is more generalized in nature (eg for a vnf-type or region).
  • blacklist-overrides
    • If a policy designer writes a filter that "whitelists" a more generalized set of vnf (eg by vnf-type or region), then any additional "blacklist" filter policies will override.


This will be the initial implementation of the filter guard. More complex scenarios will have to be explored and policy translation can be changed in the future if warranted.

Since the Policy Framework is open to multiple policies being submitted, it is a recommended best practice that the policy designer should combine all filters into a single policy for a given actor/operation combination.


Runtime Flow

  • guard calls from drools/apex PDP may will 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!.

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?)

...