OK, I did not realize this. I'm looking at the spec for TOSCA 1.2 and 1.3 on this ([3.8.8]) and it's very confusing. TOSCA 1.2 supported two notations, one for a "normal" mapping to a template, and another for mapping to inputs. In TOSCA 1.3 the first notation was removed, likely to remove confusion ... but it also removes this feature, so now it's impossible to map properties to anything other than inputs. Attribute mapping remained the same (map to an attribute or an output). Also it seems that attribute mappings allow for mapping to capability and even relationship attributes (nested). This seems to me a hijacking of the properties feature (and attributes for that matter) for an entirely different purpose. Moreover it would require the node type to be designed in such a way that it would have to match inputs ... or vice versa. This seems a very roundabout way to solve the problem. I'm inclined more and more to think that we need a very different grammar for linking the consuming service and providing service. I think what we need here is a way for the providing service to "expose" features and also for the consuming template to "inject" them. These features thus become "shared" between both services. And I think Adam's proposal is the right starting point, something that looks more like a node template than a node type, something that can be constructed rather than "mapped". One major problem with the current grammar is that mappings are one-to-one, but real world use cases are ... more complicated. But also more simple in terms of defining what users want. Here's a simple example: imagine a providing service that has two nodes, an application and a database, and that boths of these can be installed on the same server. The consuming service doesn't care that internally the providing service comprises several nodes, all it wants to do is specify "install this (whole) service on this server". There is no way to do this with substitution mapping, because you can only map the installation requirement of either node template, not both of them at once. There's this mismatch between "mapping" and the control of the actual features we need. Allow me to try to solve this with some back-of-the-napkin brainstorming by building on Adam's proposal and my idea of "exposing": # Providing service topology_template: inputs: cores: type: integer default: { @get_property: [ app, cores ] } node_templates: app: directives: - expose # shared with the consuming service type: WebApplication # this type derives from "Application" properties: name: { @get_property: [ database, capabilityname, name ] } cores: 1 attributes: id: { @get_attribute: [ database, capabilityname, nested1, nested2, id ] } requirements: - host: my-host database: type: DB requirements: - host: myhost my-host: directives: - expose # *also* shared with the consuming service type: Machine # Consuming service topology_template: node_templates: myservice: type: Application properties: cores: 5 # this will and override the value (our values here are higher priority), and thus also the property, which will then affect the input requirements: - host: my-vm my-vm: type: VirtualMachine # this type derives from "Machine" and the node will be "injected" into the providing template If you follow this example you'll see that rather than substituting a single node, we are instead "exposing" *two* nodes from the providing service. Once exposed they are essentially "shared" between the two services. The node template names are different but as long as the matching can be done correctly (by policy?) they should end up referring to the same exact node representations. Also note that the node types have to be the same or *derive from each other*. Of course references to the base type won't be able to access features of the derived type, but that is intended by design. So the consuming service only knows that this is an (abstract) "Application", while the providing template uses "WebApplication" and refers to additional properties and attributes. On the flip side, the providing service knows that it connects to an (abstract) "Machine", while the consuming service provides a concrete sub-type, "VirtualMachine". The magic of sharing means that we can indeed install both the app and db nodes on the same server. And we're no longer talking about "substitution nodes" but rather a more open sharing of one or more nodes between the two services. On Tue, Apr 13, 2021 at 11:54 AM Chris Lauwers <
lauwers@ubicity.com > wrote: This is exactly what property mappings are for. The required inputs for the substituting template are obtained from the property values of the substituted node. Thanks, Chris From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org > On Behalf Of Tal Liron Sent: Tuesday, April 13, 2021 9:48 AM To:
tosca@lists.oasis-open.org Subject: [tosca] Substitution Inputs Hello ad-hoc folk, In our discussion today about substitution mappings I forgot to mention a gaping hole in the spec: what if the substituted topology template has required inputs? There is no standard way in TOSCA to specify them. In Turandot, since I am using policies anyway (the directives are wholly insufficient), I use a custom policy property for this feature.