...
This is a page that analyzes the self serve control loops and its possible designs. Some of it might not really fit this feature but might spill over to others.
How to handle (at least) two levels of Policy parameter value filling?
...
| View file |
|---|
| name | policies.yml |
|---|
| height | 250 |
|---|
|
If the blueprints are encoded as before to CSAR, the EPC CSAR will have the file structure as shown below. The options add various files to this:
| Code Block |
|---|
$ find EPC
EPC
EPC/Artifacts
EPC/Artifacts/Resources
EPC/Artifacts/Resources/PGW
EPC/Artifacts/Resources/PGW/Deployment
EPC/Artifacts/Resources/PGW/Deployment/DCAE_INVENTORY_BLUEPRINT
EPC/Artifacts/Resources/PGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.ActiveSubscriberScaling.event_proc_bp.yaml
EPC/Artifacts/Resources/PGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.ControlPlaneScaling.event_proc_bp.yaml
EPC/Artifacts/Resources/PGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.UserPlaneScaling.event_proc_bp.yaml
EPC/Artifacts/Resources/SGW
EPC/Artifacts/Resources/SGW/Deployment
EPC/Artifacts/Resources/SGW/Deployment/DCAE_INVENTORY_BLUEPRINT
EPC/Artifacts/Resources/SGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.ActiveSubscriberScaling.event_proc_bp.yaml
EPC/Artifacts/Resources/SGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.ControlPlaneScaling.event_proc_bp.yaml
EPC/Artifacts/Resources/SGW/Deployment/DCAE_INVENTORY_BLUEPRINT/TCA-Hi-Lo.UserPlaneScaling.event_proc_bp.yaml
EPC/csar.meta
EPC/Definitions
EPC/Definitions/annotations.yml
EPC/Definitions/artifacts.yml
EPC/Definitions/capabilities.yml
EPC/Definitions/data.yml
EPC/Definitions/groups.yml
EPC/Definitions/interfaces.yml
EPC/Definitions/nodes.yml
EPC/Definitions/policies.yml
EPC/Definitions/relationships.yml
EPC/Definitions/resource-Emptyvf-template-interface.yml
EPC/Definitions/resource-Emptyvf-template.yml
EPC/Definitions/service-Emptyservice-template-interface.yml
EPC/Definitions/service-Emptyservice-template.yml
EPC/TOSCA-Metadata
EPC/TOSCA-Metadata/TOSCA.meta |
Other examples are shown without current SDC file structure for compactness. This does not affect the model properties, only the division to files
...
| View file |
|---|
| name | option2_tosca.yaml |
|---|
| height | 250 |
|---|
|
| draw.io Diagram |
|---|
| border | true |
|---|
| viewerToolbar | true |
|---|
| |
|---|
| fitWindow | false |
|---|
| diagramName | StructuralInheritanceOfPolicies |
|---|
| simpleViewer | false |
|---|
| width | |
|---|
| diagramWidth | 1011 |
|---|
| revision | 2 |
|---|
|
Evaluation
Pros
- Brings the concept of PolicyRole to design time. Something resembling this concept seems to be needed for more complex services with more complex set of control loops.
- Enable service design phase to customize arbitrary policy parameters for a particular role and service.
- Fits nicely to TOSCA syntax and semantics
...
Option 3: Inclusion to Topology Templates
Option 4: Separate Artifact for Clamp with
...
Default Policy Values
It is also possible to pass the information about the design time values for PolicyRoles outside of the main TOSCA model, similarly as the blueprint is passed now. In this case every PolicyRole would get a file in the CSAR
The main TOSCA model stays identical to Option 1.
Evaluation
Pros
- Simple separation of concerns.
Cons
- Bigger part of the service model is left outside of (main) TOSCA, making overall model handling more complex.
- Standard TOSCA tooling will not work with these
