substitution mapping and attribute mappings

[Chris Lauwers <lauwers@ubicity.com>]

There seems to be some ambiguity in the TOSCA v1.3 specification about how to best map output values from a substituting template to attribute values of the abstract node for which it is a substitution:

 

·         According to Section 3.8.13 (Substitution Mapping), the substitution mappings syntax supports an ‘attributes’ keyword that is intended to define output mappings to attributes:

 

attributes

no

map of attribute mappings

The optional map of attribute mappings allowing to map outputs from the topology template to attributes of the node_type.

 

·         However, the only place in the spec where ‘attribute mappings’ are defined is in section 3.6.15. The ‘attribute mappings’ defined in that section are intended to be used in the context of ‘operation definition’ with the goal of mapping (named) operation outputs onto attributes of nodes or relationships. This syntax is not intended to be used (nor would it be correct) for mapping attributes in the context of substitution mapping. No separate ‘attribute substitution mapping’ syntax is defined anywhere. This inconsistency in the spec needs to be addressed.

·         At the same time, it is debatable whether substitution mapping syntax needs to include attribute mappings, since those mappings are more easily defined in the abstract node type anyway by specifying attribute mappings for operation outputs, as follows:

o   Assume an abstract node (i.e. a node with a ‘substitute’ directive)

o   The node defines a ‘create’ operation on its standard interface. Because of substitution mapping, the ‘create’ operation will get mapped to the ‘deploy’ workflow of a substituting topology. I.e. when the orchestrator calls the ‘create’ operation on the abstract node, it will invoke the ‘deploy’ operation on the substituting topology

o   When the ‘deploy’ workflow completes on the substituting topology, a number of output values will be available as defined in the ‘outputs’ section of the substituting template. Presumably, these outputs will be returned as outputs of the ‘create’ operation on the abstract node (since the ‘deploy’ workflow on the substituting topology acted as the “implementation” of that create operation).  

o   These outputs can get then mapped onto attributes of the abstract node using existing ‘attribute mapping’ syntax.

·         Based on this observation, I wonder if it is really necessary to define ‘attribute mappings’ in the context of ‘substitution mappings’?

·         Of course, if we don’t define ‘attribute substitution mappings’ then we end up with an ‘asymmetry’ between ‘attribute substitution mappings’ and ‘property substitution mappings’ (i.e the mapping of properties of an abstract node to inputs of a substitution topology). Perhaps that’s OK, but at the very least we should clarify what happens if in the abstract node template, the ‘create’ operation of the Standard interface defines ‘inputs’. Is this an error, or will those values just get ignored?

·         By the way, this discussion will likely be impacted by how we plan on mapping ‘notifications’ in a substituting topology to ‘notifications’ on an abstract node. This aspect of substitution mapping needs to be clarified as well.

 

I’d love people’s perspective on this.

 

Thanks,

 

Chris