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

Compare with Current View Page History

« Previous Version 8 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

Metadata for Policy Type

  • new keyword to trigger the backend code


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