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

Compare with Current View Page History

« Previous Version 14 Next »

This page contains description Policy Types for control loops to take a baby step approach from Dublin to Frankfurt retaining a close resemblance to Dublin legacy policy types.

1. Guard Policy Type

1.1 The base schema is defined as below:

Base Policy type definition for onap.policies.controlloop.Guard 
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
  onap.policies.controlloop.Guard:
    derived_from: tosca.policies.Root
    version: 1.0.0
    description: Base definition of guard Policies for Control Loop Operational Policies
    properties:
        actor:
          type: string
          description: Specifies the Actor
          required: true
        recipe:
          type: string
          description: Specified the Recipe
          required: true
        controlLoopName:
          type: string
          description: An optional specific control loop to apply this guard policy.
          required: false
        target:
          type: string
          description: An optional specific VNF to apply this guard to.
          required: false
        time_range:
          type: tosca.datatypes.TimeInterval
          description: An optional range of time during the day the Min/Max limit is valid for.
          required: false

1.2 onap.policies.controlloop.guard.FrequencyLimiter Policy Type

Policy Typefor Frequency Limiter Guard Policy 
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
  onap.policies.controlloop.guard.FrequencyLimiter:
    derived_from: onap.policies.controlloop.Guard
    version: 1.0.0
    description: Supports limiting the frequency of actions being taken by a Actor.
    properties:
        time_window:
          type: scalar-unit.time
          description: The time window to count the actions against.
          required: true
        limit:
          type: integer
          description: The limit
          required: true
          constraints:
            - greater_than: 0

1.3 onap.policies.controlloop.guard.Blacklist Policy Type

Policy Type for Blacklist Guard Policies 
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
  onap.policies.controlloop.guard.Blacklist:
      derived_from: onap.policies.controlloop.Guard
      version: 1.0.0
      description: Supports blacklist of VNF's from performing control loop actions on.
      properties:
        blacklist:
          type: list
          description: List of VNF's
          required: true
          entry_schema:
              type: string

1.4 onap.policies.controlloop.guard.MinMax Policy Type


Policy Type for Min/Max VF Module Policies 
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
  onap.policies.controlloop.guard.MinMax:
      derived_from: onap.policies.controlloop.Guard
      version: 1.0.0
      description: Supports Min/Max number of VF Modules
      properties:
        min_vf_module_instances:
          type: integer
          required: true
          description: The minimum instances of this VF-Module
        max_vf_module_instances:
          type: integer
          required: false
          description: The maximum instances of this VF-Module

2.0 Operational Policy Type

2.1 Mapping of existing (through El Alto) Policy YAML Operational Definition

Mapping of existing Operational policy to TOSCA Policy Type 
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
    type: onap.policies.controlloop.Operational
    version: 1.0.0




Example Policy 
tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
   policies:
      -
        operational.scaleout:
           type: onap.policies.controlloop.Operational
           version: 1.0.0
           metadata:
             policy-id: operational.scaleout
           properties:
             controlLoop:
               version: 2.0.0
               controlLoopName: ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3
               trigger_policy: unique-policy-id-1-scale-up
               timeout: 1200
               abatement: false
             policies:
               - id: unique-policy-id-1-scale-up
                 name: Create a new VF Module
                 description:
                 actor: SO
                 recipe: VF Module Create
                 target:
                   type: VNF
                 payload:
                   requestParameters: '{"usePreload":true,"userParams":[]}'
                   configurationParameters: '[{"ip-addr":"$.vf-module-topology.vf-module-parameters.param[9]","oam-ip-addr":"$.vf-module-topology.vf-module-parameters.param[16]","enabled":"$.vf-module-topology.vf-module-parameters.param[23]"}]'
                 retry: 0
                 timeout: 1200
                 success: final_success
                 failure: final_failure
                 failure_timeout: final_failure_timeout
                 failure_retries: final_failure_retries
                 failure_exception: final_failure_exception
                 failure_guard: final_failure_guard


Issue: The "policies" property can be confusing with the TOSCA Topology Template value "policies".

Issue: How to ensure that CLAMP does not have to hard-code the meaning of properties. Specifically, success, failure, failure_timeout etc. - need to point to other actor/recipe's to be triggered/executed.

Issue: How to ensure that CLAMP does not have to hard-code where CSAR details need to be populated in the policy. Eg. Target Type

  • Need to use defaults, descriptions, constraints, required fields

  - Pam and Liam will work on Operational policies to look like Seb's JSON schema so Seb can test it out. Then identify next problem to solve.

Seb's JSON schema from El Alto:

https://gerrit.onap.org/r/gitweb?p=clamp.git;a=blob;f=src/main/resources/clds/json-schema/operational_policies/operational_policy.json;h=93738c80923be027781b9c2bf0fe72cfa82d7fec;hb=HEAD





  • No labels