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

Compare with Current View Page History

« Previous Version 10 Next »

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 (question): [equal | regexp | ! equal | anyof | alloff]


Do we support compound fields? AND, OR


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.

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




  • No labels