Thanks for discussing this today. What if instead of introducing a new directive like I did below we just changed syntax a "substitution_mappings" section to be the same as for node_template (plus the addition of the substitution_filter)? That would remove the potential confusion Calin pointed out. On Tue, Apr 6, 2021 at 10:14 AM adam souzis <
adam@souzis.com > wrote: sure, here's an example from TOSCA Simple Profile in YAML Version 1.3 (actually i'm combining two examples for completeness): substitution_mappings : node_type: example.TransactionSubsystem properties: rules: [ rulesInput ] capabilities: message_receiver: [ app, message_receiver ] requirements: database_endpoint: [ app, database ] node_templates: root: directives: - substitution_mapping node_type: example.TransactionSubsystem properties: rules: {get_input: rulesInput } capabilities: message_receiver: property1: {get_property: [app, message_receiver, property1 ] requirements: database_endpoint: node: database # direct reference to app database requirement target node # topology outputs could be mapped to attributes attributes: output1: {get_attribute: [app, attribute1]} The main expressiveness I see missing compared to the subsitution_mapping is that I have to directly specify the requirement target node; this could be solved by introducing a "get_requirement" TOSCA function so we could write this: {get_requirement: [app, database]} Adam On Tue, Apr 6, 2021 at 8:37 AM Tal Liron <
tliron@redhat.com > wrote: Adam, could you possibly write out an example of using a node template instead of using substitution mapping? It will help me understand what exactly you have in mind (I think I do, but not sure). On Tue, Apr 6, 2021 at 10:14 AM adam souzis <
adam@souzis.com > wrote: Thanks for discussing this on the call today... I feel like I am missing something -- assuming that this "root" node template is "virtual" in the same with the same semantics as a substitution_mapping -- is there anything that the "substitution_mapping" syntax can express that a node_template can't syntactically? Not saying this is a good idea or not -- I'm just trying to make sure I understand this... On Tue, Apr 6, 2021 at 5:50 AM adam souzis <
adam@souzis.com > wrote: 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 On Mon, Apr 5, 2021 at 9:41 PM Chris Lauwers <
lauwers@ubicity.com > wrote: We will discuss substitution mapping Specifically as it relates to exchanging information between the substituted node and the substituting template Thanks, Chris