[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Substitution Inputs
|
Hi Tal, comments inline From: Tal Liron <tliron@redhat.com>
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).
The reason that direct âproperty-to-propertyâ mappings were removed is because they donât work: the starting assumption is that a substituting template needs to be a valid TOSCA template,
independent of substitution mapping. This means that all required properties must have values assigned. If property mappings were to assign different values to those same properties, then we have a conflict resulting in non-deterministic behavior. Mapping
all properties through inputs is the only way to make this work consistently. In addition, the 1.3 spec does not actually define attribute mappings as part of substitution mappings. It makes reference to attribute mapping syntax, but the only attribute mapping
syntax defined in the spec is for mapping operation outputs to attributes on node or relationships. The âattribute mappingâ aspect of substitution mapping needs a lot more discussion. In my implementation, I donât support attribute mappings. Instead, I use
the outputs defined in a service template and map them onto the operation outputs for the âcreateâ operation in the substituted node. In my opinion, this is the only approach that makes sense, but it results in asymmetry between handling of inputs and outputs.
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. This shouldnât affect node type design. It is the responsibility of the substituting template to make sure all its required input values can be obtained from a property value in the substituted node somehow. I'm inclined more and more to think that we need a very different grammar for linking the consuming service and providing service. We should not think of this in terms of âclient/serverâ or âconsuming service/providing serviceâ. This is simple decomposition (component/system pattern), nothing more, nothing less. 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". Again, in my opinion this is not the correct way to think about this. The substituted node doesnât care (nor should it have to) about the âfeaturesâ of the substituting template. The substituting template is strictly
an implementation of the features exposed by the substituted node. There is no âinjectionâ of anything, just implementation.
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. The pattern of âinstall a bunch of things on the same serverâ is independent of substitution mapping. The current solution in TOSCA is to use âselectableâ nodes for this purpose. However, we donât have a way (as
part of substitution mapping) to map a requirement onto a selectable node. However, there are other mechanisms to accomplish the same result (using node filters). 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.
This implements a very different paradigm than what weâre trying to do with substitution mapping, in my opinion. The minute you talk about âexposingâ you now assume that the substituted
node will be aware of what is âexposedâ by the substituting template. This violates the idea of âabstractionâ that is the foundation of substitution mapping. The whole point is that a substituted node doesnât care about how it is implemented internally.
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. If âsharingâ is your goal, then you should use requirement fulfillment (likely using selectable nodes), not substitution mapping. The objective of these two (very different) features is not the same. On Tue, Apr 13, 2021 at 11:54 AM Chris Lauwers <lauwers@ubicity.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]