You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

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

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:

  • DCAE will generate a lot of 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

Guard Filter Policy Type and Sample Policies 
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 - 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.


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.


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


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




  • No labels