From our discussion, I think itâs clear that we need to do a better job of explaining the âsubstitution mappingâ paradigm (i.e. that it is an implementation of the component/system pattern). In light of that observation, I think it would
be a mistake to define âsubstitution mappingsâ as part of node template grammar, since it would make it less clear that âsubstitutionâ applies to the topology as a whole, not to a single node in that topology.
Chris
From: adam souzis <adam@souzis.com>
Sent: Tuesday, April 13, 2021 8:21 AM
To: Tal Liron <tliron@redhat.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Agenda for Tuesday Apr. 6, 2021 TOSCA Language Ad-Hoc meeting
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.
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:
capabilities:
message_receiver: [ app,
message_receiver ]
requirements:
database_endpoint: [ app,
database ]
node_type: example.TransactionSubsystem
rules: {get_input: rulesInput }
property1: {get_property: [app,
message_receiver, property1]
node: database # direct reference to app database requirement target node
# topology outputs could be mapped to 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, 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).
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...
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.
-
We will discuss substitution mapping
-
Specifically as it relates to exchanging information between the substituted node and the substituting template
Thanks,
Chris
|