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 template | Notes |
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
| the virtualLink requirement of the internal node extcp0
is explicitly mapped onto an external requirement using
the standard TOSCA substitution mapping syntax 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 template | Notes |
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
| the virtualLink requirement of the internal node extcp0
is explicitly mapped onto an external requirement using
the standard TOSCA substitution mapping syntax 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.
|
|---|