Up until 1.1, the TOSCA substitution mappings grammar only allowed for exposure of capabilities and requirements. Mapping of the node type properties to the inputs of the implementing topology was not supported. ONAP used to work around this TOSCA limitation by using a special naming convention for properties and inputs. For each input defined by the designer for a VNF or service topology, SDC generated a property with exactly the same name on the substituting node type. The run-time components also relied on this hidden "same name" convention to pair between a node property and an input of the node's implementing topology.

TOSCA 1.2 extended the substituting mappings construct and made possible to map the properties of a node type to the inputs of the implementing topology in a clear, declarative and standard way.


Casablanca property-to-input mapping based on TOSCA 1.1

Node type definition (VNF)Implementing topology templateNotes

node_types:
org.openecomp.resource.vf.Vnf1:
derived_from: org.openecomp.resource.abstract.nodes.VF
properties:
nf_role:
type: string
## other properties omitted for brevity
requirements:
- extcp0.virtualLink:
occurrences: [1, UNBOUNDED]
capability: tosca.capabilities.network.Linkable
relationship: tosca.relationships.network.LinksTo
## other capabilities and requirements omitted for brevity

topology template:
inputs:
nf_role:
type: string
## other inputs omitted for brevity
node_templates:
extcp0:
# ... has a requirement named extcp0.virtualLink

substitution_mappings:
type: org.openecomp.resource.vf.Vnf1
requirements:
extcp0.virtualLink:
- extcp0
- virtualLink

  1. the virtualLink requirement of the internal node extcp0
    is explicitly mapped onto an external requirement using
    the standard TOSCA substitution mapping syntax
  2. the nf_role input of the implementing topology is
    implicitly mapped onto an external property using
    the "same name" naming convention, because the
    TOSCA 1.1 syntax does not support this kind of mapping



Dublin property-to-input mapping based on TOSCA 1.2

Node type definition (VNF)Implementing topology templateNotes

node_types:
org.openecomp.resource.vf.Vnf1:
derived_from: org.openecomp.resource.abstract.nodes.VF
properties:
nf_role:
type: string
## other properties omitted for brevity
requirements:
- extcp0.virtualLink:
occurrences: [1, UNBOUNDED]
capability: tosca.capabilities.network.Linkable
relationship: tosca.relationships.network.LinksTo
## other capabilities and requirements omitted for brevity

topology template:
inputs:
nf_roleXXX:
type: string
## other inputs omitted for brevity
node_templates:
extcp0:
# ... has a requirement named extcp0.virtualLink

substitution_mappings:
type: org.openecomp.resource.vf.Vnf1
requirements:
extcp0.virtualLink:
- extcp0
- virtualLink

properties:

nf_role: nf_role_XXX


  1. the virtualLink requirement of the internal node extcp0
    is explicitly mapped onto an external requirement using
    the standard TOSCA substitution mapping syntax
  2. the nf_roleXXX input of the implementing topology is
    explicitly mapped onto an external property using
    the property mapping syntax introduced in TOSCA 1.2.

    The paired input and property do not have to have the same
    name now.



  • No labels