tliron / puccini

Cloud topology management and deployment tools based on TOSCA
https://puccini.cloud
Apache License 2.0
88 stars 20 forks source link

could not satisfy "..." because no candidate node template provides required capability #97

Closed philippemerle closed 2 years ago

philippemerle commented 2 years ago

The following attached file contains a sophisticated ETSI NFV SOL 001 example : example.zip.

Then compiling it produces several problems:

$ puccini-tosca compile --quirk etsinfv --quirk capabilities.occurrences.permissive example/example_A.18-01.yaml
PROBLEMS (7)
  Resolution
    @144,26 topology_template.node_templates["lb_mciop"].requirements{0}: could not satisfy "associatedVdu" because no candidate node template provides required capability
  file:/Users/merle/Documents/CLOUDNET/inria-gitlab/use-cases/etsi-nfv-sol-001/4.0.11/puccini-issues/example/example_A.18-01.yaml
    @126,11 topology_template.node_templates["VNF"].artifacts["helm_test"]: URL not found: Artifacts/Tests/helm_test.sh
...

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?

philippemerle commented 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
philippemerle commented 2 years ago

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.

philippemerle commented 2 years ago

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
tliron commented 2 years ago

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.