In preparations for this meeting I struggled to understand the semantic of substitution mappings and come to the conclusion that they aren't needed!
* If a substituted node template is chosenÂby the orchestrator from its inventory than I don't see why we need a separate "substitute" directive -- "select" shouldÂbe sufficient. Why should the template care about what mechanism the orchestrator uses to pick a nodeÂin its inventory? Regarding the node template's properties: they just have to be present as specified, if that implies that the orchestrator will fulfillÂthat that by passing them through as inputs to another template that seems irrelevant to the outer node template.Â
* All the functionality of "substitution_mappings" is available by simply adding a node template directive like "export" or "root" which indicates that that node_template should be used to "represent" the topology. That node template is already as expressive as a substitution_mapping:
- input mappings are available through get_input
- capabilities mappings can be specified using get_property
- requirements mappings just need to declare the target node directly.
I think simplifyingÂthe spec like this would be a big win.
BTW version 1.3 describes "substitutions_mappings" as a list its grammar -- I assume that's an error but that could be supported in this proposal simply by allowing multiple node templates to use this "export" directive.
Cheers,
Adam