Closed philippemerle closed 2 years ago
Following is a minimalized version of example_A.18-01.yaml:
# Simplified version of A.18-01.yaml
tosca_definitions_version: tosca_simple_yaml_1_3
description: A sample VNF descriptor with containerized VDUs
imports:
- etsi_nfv_sol001_vnfd_types.yaml # VNFD definitions based on SOL001 v4.2.1 draft
topology_template:
node_templates:
lb_mciop:
type: tosca.nodes.nfv.Mciop
requirements:
- associatedVdu: Vdu_1
VirtCp1:
type: tosca.nodes.nfv.VirtualCp
properties:
layer_protocols: [ ipv6 ]
additionalServiceData: []
requirements:
- target: Vdu_1
Vdu_1:
type: tosca.nodes.nfv.Vdu.OsContainerDeployableUnit
properties:
name: "lb"
description: "Advanced Software Load Balancer"
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 4
requirements:
- container: Vdu_1_Container_1
Vdu_1_Container_1:
type: tosca.nodes.nfv.Vdu.OsContainer
properties:
name: "lb Container"
description: "Advanced Software Load Balancer"
$ puccini-tosca compile issue_97.yaml
PROBLEMS (1)
Resolution
@12,26 topology_template.node_templates["lb_mciop"].requirements{0}: could not satisfy "associatedVdu" because no candidate node template provides required capability
I supposed that puccini correctly does the work :-) Then I suspected that the example contains a defect :-(
$ puccini-tosca compile -vv issue_97.yaml
...
2022/02/06 14:47:09.758 DEBUG [puccini.js] {tosca.resolve} topology_template.node_templates["VirtCp1"].requirements{0}: satisfied "target" with capability "associable" in node template "Vdu_1"
...
2022/02/06 14:47:09.758 DEBUG [puccini.js] {tosca.resolve} topology_template.node_templates["lb_mciop"].requirements{0}: capability "associable" in node template "Vdu_1" already has 1 relationships, the maximum allowed
PROBLEMS (1)
Resolution
@12,26 topology_template.node_templates["lb_mciop"].requirements{0}: could not satisfy "associatedVdu" because no candidate node template provides required capability
└─/home/emblemparade/go/pkg/mod/github.com/dop251/goja@v0.0.0-20220124171016-cfb079cdc7b4/runtime.go:2289
$
The associatedVdu
requirement of lb_mciop
should be connected to the associable
capability of Vdu_1
but this capability was already consumed by the target
requirement of VirtCp1
.
The problem is in the example: several capabilities (feature
, virtual_binding
, associable
) of Vdu_1
could match the target
requirement of VirtCp1
, so here is the design defect.
Puccini correctly selects the associable
capability of Vdu_1
and then raises a problem when trying to satisfy the associatedVdu
requirement of lb_mciop
.
Another TOSCA parser could correctly select the feature
capability of Vdu_1
and then could satisfy the associatedVdu
requirement of lb_mciop
with the associable
capability of Vdu_1
.
Then this example is strongly dependent of the TOSCA parser algorithm for satisfying requirements. This example is incorrect for puccini but could be considered as correct by another parser. So this example is ambiguous and the issue shall be reported to the working group defining the ETSI NFV SOL 001 specification.
Following is an ultra-simplified version of the template that illustrates the problem:
# Inspired from ETSI NFV SOL 001 v2.4.2 example A.18-01.yaml
tosca_definitions_version: tosca_simple_yaml_1_3
capability_types:
tosca.capabilities.nfv.AssociableVdu:
derived_from: tosca.capabilities.Node
relationship_types:
tosca.relationships.nfv.MciopAssociates:
derived_from: tosca.relationships.DependsOn
valid_target_types: [ tosca.capabilities.nfv.AssociableVdu ]
node_types:
tosca.nodes.nfv.Mciop:
derived_from: tosca.nodes.Root
requirements:
- associatedVdu:
capability: tosca.capabilities.nfv.AssociableVdu
relationship: tosca.relationships.nfv.MciopAssociates
tosca.nodes.nfv.VirtualCp:
derived_from: tosca.nodes.Root
requirements:
- target:
capability: tosca.capabilities.Node
relationship: tosca.relationships.DependsOn
tosca.nodes.nfv.Vdu.OsContainerDeployableUnit:
derived_from: tosca.nodes.Root
capabilities:
associable:
type: tosca.capabilities.nfv.AssociableVdu
occurrences: [ 1, 1 ]
topology_template:
node_templates:
lb_mciop:
type: tosca.nodes.nfv.Mciop
requirements:
- associatedVdu: Vdu_1
VirtCp1:
type: tosca.nodes.nfv.VirtualCp
requirements:
- target: Vdu_1
Vdu_1:
type: tosca.nodes.nfv.Vdu.OsContainerDeployableUnit
Thanks again for taking time to investigate and narrow down on the issue.
In this case, I think it was a bug. :( The implementation of the capabilities.occurrences.permissive
quirk was missing one part of the algorithm, so it wasn't actually working correctly. This is fixed in the latest commit.
By the way, no need to use both etsinfv
and capabilities.occurrences.permissive
because the latter is included in the former.
GitHub will automatically close this with the commit, but feel free to reopen if you think the issue is not resolved and/or different.
The following attached file contains a sophisticated ETSI NFV SOL 001 example : example.zip.
Then compiling it produces several problems:
I don't success to understand the first reported problem. I understand well next six problems. What is the problem in this example? Or is it a puccini issue?