This design proposal is to use a common base Policy Type with a common header for all possible Control Loop Policy Types. In doing so, we gain the following benefits:
- Organization: All policies for a control loop can be organized more easily because the field that uniquely identifies the Control Loop is in a common place where CLAMP can easily find and set.
- Problem #1 solved: All the current policy types have a different field name for the unique identity of the Control Loop
- Problem #2 solved: All the current policy types locate that field in a different hierarchy within each policy type.
- Extendability: Future Control Loop policy types can be designed without hard coding into CLAMP where to find the unique id for the control loop
1.0 Base Control Loop Policy Type
ALL Control Loop Policy Types derive from this so that CLAMP as well as auditing/monitoring tools can organize/find all the policies associated with a Control Loop.
ISSUE #1: Should this be a list??
Base Control Loop Datatype for ALL Control Loop Policy Types
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.Root:
derived_from: tosca.policies.Root
version: 1.0.0
description: Root policy type for all Control Loop Policies
properties:
controlLoopId:
type: string
required: true
description: The unique ID identifying the control loop. There are no semantic meaning tied to this name.
2.0 Example Usages of Base Control Loop Policy Type
The following shows how the base Control Loop Policy Type can be used.
2.1 How current Policy Types would derive from Base Control Loop Policy Type
As of Dublin/El Alto, we have these Policy Types that will need to derive from the base type.
- CLAMP will be able to search for Monitoring Policy Types to associate with DCAE uS
- CLAMP will be able to search for all possible guard and operational Policy Types
Base Control Loop Policy Types
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.Root:
derived_from: tosca.policies.Root
version: 1.0.0
description: Root policy type for all Control Loop Policies
properties:
controlLoopId:
type: string
required: true
description: The unique ID identifying the control loop. There are no semantic meaning tied to this name.
onap.policies.controlloop.root.Monitoring:
derived_from: onap.policies.controlloop.Root
version: 1.0.0
description: Base Control Loop Policy Type for all Monitoring Policy Types
properties:
# common properties shared between all Monitoring policy Types
# ommitted due to brevity
onap.policies.controlloop.root.Operational:
derived_from: onap.policies.controlloop.Root
version: 1.0.0
description: Base Control Loop Policy Type for all Operational Policy Types
properties:
# common properties shared between all Operational policy Types
# ommitted due to brevity
onap.policies.controlloop.root.Guard:
derived_from: onap.policies.controlloop.Root
version: 1.0.0
description: Base Control Loop Policy Type for all Guard Policy Types
properties:
# common properties shared between all Guard policy Types
# ommitted due to brevity
QUESTION/ISSUE: Should Control Loop Coordination have its own base type? Or is it still a guard?
2.2 Example Policy Types deriving from each Base Control Loop Policy Type
Each base Policy Type can then be further defined for specifics.
Specific Control Loop Policy Types
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.root.monitoring.Threshold:
derived_from: onap.policies.controlloop.root.Monitoring
version: 1.0.0
description: Threshold crossing DCAE uS Monitoring Policy Type
properties:
tca_policy:
type: map
description: TCA Policy JSON
entry_schema:
type: onap.datatypes.monitoring.tca_policy
onap.policies.controlloop.root.operational.Drools:
derived_from: onap.policies.controlloop.root.Operational
version: 1.0.0
description: Drools Operational Policy Types
properties:
# ommitted due to brevity
onap.policies.controlloop.root.operational.Apex:
derived_from: onap.policies.controlloop.root.Operational
version: 1.0.0
description: Apex Operational Policy Types
properties:
# ommitted due to brevity
onap.policies.controlloop.root.guard.Frequency:
derived_from: onap.policies.controlloop.root.Guard
version: 1.0.0
description: Frequency limiter guard policy
properties:
# ommitted due to brevity
onap.policies.controlloop.root.guard.Blacklist:
derived_from: onap.policies.controlloop.root.Guard
version: 1.0.0
description: Blacklist Control Loop guard policy
properties:
# ommitted due to brevity
onap.policies.controlloop.root.guard.MinMax:
derived_from: onap.policies.controlloop.root.Guard
version: 1.0.0
description: MinMax guard policy
properties:
# ommitted due to brevity
onap.policies.controlloop.root.guard.Coordination:
derived_from: onap.policies.controlloop.root.Guard
version: 1.0.0
description: Control Loop Coordination guard policy
properties:
# ommitted due to brevity
2.3 Example Policies for Scale Out Use Case
3.0 Benefits:
- All other Control Loop Policy Types then derive from this base type
- CLAMP is now able to search the CSAR and/or Policy Lifecycle API to find ALL possible Policy Types that derive from "onap.policies.controlloop.Root"
- Problem solved: will not have to hard code inside the platform what Policy Types it supports.
- Control Loop Designers can find the Control Loop Policy Types they wish to use in their control loop and pick and choose them.
- Eg. A specific operational policy for a PDP engine (Drools vs Apex)
- Eg. Desired guard policies
- When DCAE becomes Model Driven, CLAMP should be able to find the Monitoring Policy Types associated with each DCAE uS
- ONAP users can now define their own Control Loop Policy Types
- NOTE: They will still have to create applications/controllers