...
| Code Block |
|---|
|
tosca_definitions_version: tosca_simple_yaml_1_0_0
topology_template:
policies:
- operational.sampleusecase1:
type: onap.policies.controlloop.operational.Sampleusecase1
type_version: 1.0.0
type_impl: onap.policies.controlloop.operational.sampleusecase1.Impl
type_impl_version: 1.0.0
version: 1.0.0
metadata:
policy-id: operational.sampleusecase1
properties: null
- operational.sampleusecase2:
type: onap.policies.controlloop.operational.Sampleusecase2
type_version: 1.0.0
type_impl: onap.policies.controlloop.operational.sampleusecase2.Impl
type_impl_version: 1.0.0
version: 1.0.0
metadata:
policy-id: operational.sampleusecase2
properties:
ClosedLoopControlName: sample-usecase-1 |
| Code Block |
|---|
|
tosca_definitions_version: tosca_simple_yaml_1_0_0
policy_types:
onap.policies.controlloop.operational.Sampleusecase1:
derived_from: onap.policies.controlloop.Operational
description: a sample use case1 specific policy type
version: 1.0.0
onap.policies.controlloop.operational.Sampleusecase2:
derived_from: onap.policies.controlloop.Operational
description: a sample use case2 specific policy type
version: 1.0.0
properties:
ClosedLoopControlName:
type: string
required: true
description: the controlloop name for sample use case2 |
Note that the preceding policy type implementation list contains two elements. One is for sample use case1 rules whereas the other is for sample use case2 rules. Here, sample use case 1 and 2 are two example use cases which use drools rules for decision making. Let's assume sample use case1 rules do not have configurable properties while sample use case 2 rules contain configurable properties (e.g. ${ClosedLoopControlName}), which justifies that in the corresponding policies created off, we can see "properties: null" for use case 1 and "properties: ClosedLoopControlName: xxx" for use case 2 as shown above.
...