Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 3 Next »

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.


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


  • No labels