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.GuardExpand source
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
operation:
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 PolicyExpand source
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 PoliciesExpand source
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 PoliciesExpand source
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
Example Policy - one-2-one mapping of the El Alto YAML operation definitionExpand source
2.2 Use of NodeTypes and CapabilityTypes to support Actor/Operation definition
Mapping of existing Operational policy to TOSCA Policy TypeExpand source
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.operational.Common:
derived_from: tosca.policies.Root
version: 2.0.0
description: Operational Policy for Control Loop execution
properties:
id:
type: String
description: The unique control loop id
required: true
timeout:
type: Integer
description: Overall timeout for executing all the operations.
required: true
onset:
description: The datatype of the expected ONSET Control Loop Event
required: true
entry_schema:
type: onap.datatype.controlloop.Event
abatement:
type: Boolean
description: Whether an abatement will be expected for the control loop.
required: true
default: false
operation:
description: Initial operation to execute upon receiving an Onset event for the Control Loop.
required: true
entry_schema:
type: onap.datatype.controlloop.operation.Directive
onap.policies.controlloop.operational.common.Apex:
derived_from: onap.policies.controlloop.operational.Common
version: 1.0.0
description: Operational policies for Apex PDP
properties:
onap.policies.controlloop.operational.common.Drools:
derived_from: onap.policies.controlloop.operational.Common
version: 1.0.0
description: Operational policies for Drools PDP
properties:
controller:
description: Drools controller properties
required: true
entry_schema:
type: onap.datatype:controlloop.controller.Drools
data_types:
onap.datatype.controlloop.Event:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: Definition of the target type for operations during control loops
properties:
event_type:
type: String
required: true
default: "Legacy"
constraints:
- valid_values: ["Legacy", "VES"]
event_version:
type: String
required: true
default: "1.0.0"
onap.datatype:controlloop.controller.Drools:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: Definition of the target type for operations during control loops
properties:
# TBD
onap.datatype.controlloop.TargetType:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: Definition of the target type for operations during control loops
properties:
target:
type: String
description: The type target the operation is performed against.
required: true
constraints:
valid_values: [VNF, VM, VNFC, VFMODULE, PNF]
resources:
type: String
description: |
The resource in which the operation is be performed against. By default,
an onset event will contain resource identification which should be used
for the operation (if applicable) if this field is missing.
onap.datatype.controlloop.Operation:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: An operation supported by an actor
properties:
id:
type: String
description: Unique identifier for the operation
required: true
targettype:
description: The target type supported by the operation
required: true
entry_schema:
type: onap.datatype.controlloop.TargetType
parameters:
type: Map
description: Optional parameters required by the operation
required: false
payload:
type: Map
description: Optional payload that is passed from the policy to the actor for operation execution.
onap.datatype.controlloop.operation.Directive:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: Policy definitions for taking actions during a Control Loop event
properties:
id:
type: String
description: Unique ID for the operation
required: true
description:
type: String
description: A user-friendly description of the directive
required: false
actor:
description: The actor that will perform the operation
required: true
entry_schema:
type: onap.nodetype.controlloop.Actor
operation:
description: The operation the actor should perform on the target
required: true
entry_schema:
type: onap.datatype.controlloop.operation
target:
description: The target this operation is performed against
required: true
entry_schema:
type: onap.datatype.controlloop.targettype
timeout:
type: Integer
description: The amount of time for the actor to perform the operation.
required: true
retries:
type: Integer
description: The number of retries the actor should attempt to perform the operation.
required: true
default: 0
success:
description: Points to the operation to invoke on success.
required: false
default: final_success
entry_schema:
type: onap.datatype.controlloop.operation.directive
failure:
description: Points to the operation to invoke on Actor operation failure.
required: false
default: final_failure
entry_schema:
type: onap.datatype.controlloop.operation.directive
failure_timeout:
description: Points to the operation to invoke when the time out for the operation occurs.
required: false
default: final_failure_timeout
entry_schema:
type: onap.datatype.controlloop.operation.directive
failure_retries:
description: Points to the operation to invoke when the current operation has exceeded its max retries.
required: false
default: final_failure_retries
entry_schema:
type: onap.datatype.controlloop.operation.directive
failure_exception:
description: Points to the operation to invoke when the current operation causes an exception.
required: false
default: final_failure_exception
entry_schema:
type: onap.datatype.controlloop.operation.directive
failure_guard:
description: Points to the operation to invoke when the current operation is blocked due to guard policy enforcement.
required: false
default: final_failure_guard
entry_schema:
type: onap.datatype.controlloop.operation.directive
node_types:
onap.nodetype.controlloop.Actor:
derived_from: tosca.nodes.Root
version: 1.0.0
description: Actor involved in executing operations in a control loop
properties:
id:
type: String
description: Unique identifier for the actor
required: true
capabilities:
operation:
type: onap.controlloop.capability.Operation
capabilities:
type: List
description: List of operations available for the actor
required: true
entry_schema:
type: onap.datatype.controlloop.Operation
capability_types:
onap.controlloop.capability.appc.ModifyConfig:
derived_from: tosca.nodes.Capabilities
properties:
topology_template:
node_templates:
onap.nodetype.controlloop.actor.Appc:
type: onap.nodetype.controlloop.Actor
id: APPC
description: APPC control loop actor
capabilities:
ModifyConfig:
type: onap.controlloop.capability.appc.ModifyConfig
onap.nodetype.controlloop.actor.AppcLcm:
type: onap.nodetype.controlloop.Actor
id: APPCLCM
description: APPC LCM control loop actor
capabilities:
Restart:
type: onap.controlloop.capability.appclcm.Restart
Rebuild:
type: onap.controlloop.capability.appclcm.Rebuild
Migrate:
type: onap.controlloop.capability.appclcm.Migrate
ConfigModify:
type: onap.controlloop.capability.appclcm.ConfigModify
onap.nodetype.controlloop.actor.Cds:
type: onap.nodetype.controlloop.Actor
id: CDS
description: CDS control loop actor
capabilities:
ModifyConfig:
type: onap.controlloop.capability.cds.ModifyConfig
onap.nodetype.controlloop.actor.Sdnc:
type: onap.nodetype.controlloop.Actor
id: SDNC
description: SDNC control loop actor
capabilities:
reroute:
type: onap.controlloop.capability.sdnc.reroute
BandwidthOnDemand:
type: onap.controlloop.capability.sdnc.BandwidthOnDemand
onap.nodetype.controlloop.actor.Sdnr:
type: onap.nodetype.controlloop.Actor
id: SDNR
description: SDNR control loop actor
capabilities:
ModifyConfig:
type: onap.controlloop.capability.sdnr.ModifyConfig
onap.nodetype.controlloop.actor.So:
type: onap.nodetype.controlloop.Actor
id: SO
description: SO control loop actor
capabilities:
VFModuleCreate:
type: onap.controlloop.capability.so.VFModuleCreate
VFModuleDelete:
type: onap.controlloop.capability.so.VFModuleDelete
onap.nodetype.controlloop.actor.Vfc:
type: onap.nodetype.controlloop.Actor
id: VFC
description: VFC control loop actor
capabilities:
Restart:
type: onap.controlloop.capability.vfc.Restart
2.2 Mapping using TOSCA Triggers
Expand source
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.operational.TriggerStylePolicyType:
derived_from: tosca.policies.Root
version: 1.0.0
description: Operational Policy for Control Loop execution using Triggers
metadata:
properties:
controlLoopName:
type: string
description: The unique control loop id
required: true
timeout:
type: integer
description: Overall timeout for executing all the operations in the policy.
required: true
targets: [] # optional must be Node Types or Group Types applied to
triggers: # ?
topology_template:
policies:
-
firewall_restart:
type: onap.policies.controlloop.operational.TriggerStylePolicyType
description: vFirewall use case - APPC restart
metadata:
properties:
controlLoopName: ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a
timeout: 1200s
targets: [] # optional must be Node Templates or Groups applied to
triggers:
-
on_onset:
description: When the ONSET event is received
event_type: ControlLoopEvent
schedule:
start_time: T06:00:00Z
end_time: T23:59:59Z
target_filter:
node:
requirement:
capability:
condition:
action: # scripts?
primary: # The optional implementation artifact (i.e., the primary script file within a TOSCA CSAR file).
dependencies: # The optional ordered list of one or more dependent or secondary implementation artifacts which are referenced by the primary implementation artifact
timeout: # timeout in seconds
operation_host: # node executed on
constraint: # seems the same as condition above
period: 300s
evaluations: 3 # is this retries? The optional number of evaluations that must be performed over the period to assert the condition exists.
method: # optional statistical method name to use to perform evaluation of condition
Issue: The "policies" property can be confusing with the TOSCA Topology Template value "policies".
Pamela Dragosh - use "operations" instead since it really is a set of operations that are really being enforced.
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.
Issue: TOSCA Constraints would be nice to have something with suggested values, so the policy isn't locked into a set of values. Example is "actors" - ONAP has a set of actors, but it would be nice to be able to extend to other internal actors companies support.
# REST of policy ommitted for brevity
onap.datatype.controlloop.operationalpolicies:
derived_from: tosca.datatypes.Root
version: 1.0.0
description: Policy definitions for taking actions during a Control Loop event
properties:
# other properties ommitted for brevity
actor:
type: String
description: The actor that will perform the operation
required: true
constraints:
possible_values: [SO, SDNC, APPC, VFC, SNDR, CDS]
Issue: TOSCA does NOT have a way to relate properties together. For example, if the actor property is selected as APPC, then the contraints (eg possible values) for the operation property SHOULD be "restart", "reboot", "modifyConfig". How can that be specified?
Issue: Can/Should we consolidate onap.policies.Operational into a common policy type and then allow Drools and Apex (or be extendable to companies ingesting ONAP) to be derived_from that policy.
Question: Should the actor be a capability? If its a datatype, then you cannot pre-define them. A capability type would allow us to predefine actors as well as allow companies that ingest ONAP to create their own.
Question: How does CLAMP call CDS API for blueprint information? to be filled in
TODO: Pam add examples.
Question: If CSAR is prepopulated with datatypes and policytypes, how would one design a PNF control loop? Do we need a PNF service distributed to it to "kick off"?
Issue: Can we specify the guard policies into the operational policies? Do we make guard optional in policy operational directive executive? How to make it available to all PDP engines?
Could switch to where a selection of the operation constrains the actor.
Instead of specify BOTH actor and operation, select an operation and then the actor supported by the operation.
Issue: Policies and Reusable Operations Action Item Follow up - Jorge Hernandez
A nested policy approach has the following issues:
Number of hierarchical layers, which must be bounded. The CLAMP GUI driven by an open ended "recursive" schema would have to be bounded. One could argue that after N hierarchical layers, the information would be hard to be tracked by a human operator.
Associated with the number of hierarchical layers, and the most important issue is the duplication of operations, as duplicated operations would be repeated at multiple levels, and branches.
Associated with (2), there are issues of conciseness and human readability of policies.
A smaller issue relates to the storage space in the policy repository as it would likely require more space due to dups operations across levels.
A smaller issue relates to come up with canonical representation of policies and operations, policies will have to be flattened out and put in a canonical representation to support static analysis on the policy repo, for example for conflict detection.
The main benefits for nested operations over a flat structure are:
Clearly drive the GUI display and the user input (may be more intuitive), and
if the operations are fairly simple (policies mono-operational) which is the high runner case at this time (minimum duplication).
Recommendation is to stay with the flat structure previously used vs nested. Not ideal but use description field as a way of instructing the user on what values to put in the fields.
Determined that we need a catalog for actors/operations and what target they work on