Chris, your characterization of my approach is entirely incorrect.
I absolutely agree with the charter, which I helped pen, and do think TOSCA should have Day 1 and indeed Day 2 characteristics. I started my email and then concluded my email by stating exactly that. In the same way, our disagreements over interfaces and operations are about me wanting TOSCA to have a proper and real event model that is ready for Day 2. I prefer to have relationships as "potentials", in the same way node templates are "potentials", for the same reasons. I always prefer attributes and other forms of dynamism and want us to take them more seriously.
I'm very glad you dug up section 2.9.2. That example text has existed pretty much unchanged since TOSCA 1.0 (when it didn't use a directive), but always looked like an aberration (there are many similar sections that are confusing or conflicting). It is the only place in the whole spec where we see an example of
the "node_filter" keyword at the node template level and none of the other examples ever refer to this feature. Everywhere else "node_filter" is used for requirements. If we can now all agree that section 2.9.2 is definitive then that would be an excellent starting point for us to move forward.
(As I said, we don't need a new directive and if we accept "select" for this, I am fine with that. Also at the end of my email I mentioned that we can think of other syntactical ways to express selection constraints, so again, if we accept 2.9.2 as the definitive use of node_filter at the template level, I am also fine with that. But that means it is very different from its use at the requirement level. Requirements filter other nodes, but the node template node_filter applies to the node itself. Thus I would recommend keeping the functionality but renaming the keyword.)
More comments inline:
There is not âheuristicâ for determining if a requirement is dangling, nor is there a need to introduce a âdanglingâ keyword. If a requirement does not have a target node assigned
in a template, it is dangling. There is nothing more to it.
This is a disaster. It means a TOSCA template designer cannot know if their design is complete. It goes against the central reason I promote TOSCA and is a non-starter for me. The only feature of runtime selection I will agree on is in section 2.9.2.
It's not about me saying that TOSCA is "only" for Day 0. It's me saying that this is unnecessarily sacrificing Day 0 for Day 1. There are much better ways.
Many orchestrators have internal languages that handle Day 1 features, and indeed they do so much better than TOSCA does or can do, because they don't have to be agnostic. They can tightly integrate with the specific features of the particular orchestrator for which they are designed. But where TOSCA shines is in its excellent Day 0 support, being strongly typed and strongly validated. This is exactly because of its agnosticism: it must support "profiles" by design, and thus has to have strong grammar to support them. This extra design verbosity pays off in spades for Day 0. And the graph is central to this. Where would TOSCA be without requirements and capabilities? Crippling this crucial feature will turn TOSCA into a much less interesting language.
Â
While âselectâ nodes are semantically the same as dangling requirements, we cannot just replace all dangling requirements with select nodes, since they donât support requirement
mapping in substitution mapping. Dangling requirements are the âexternally-visible pinsâ through which topologies can be stitched together with other topologies. Select nodes cannot provide that functionality.
You are correct in pointing out this use case, and indeed that is the ONLY place in which I allow requirements to not be fulfilled. Basically Puccini looks at the list of requirements mapped under substitution_mappings and marks those as being special. They are then removed from general consideration during the requirement fulfillment algorithm for that topology. Actually it's quite different from how you understand "dangling" requirements, because in this case mapped requirements cannot be fulfilled in the current template. Mapped requirements should never be fulfilled locally.
So, if we agree that this is the only place that unfulfilled requirements are allowed, then again this is a good place for us to move forward. I will adamantly disagree on allowing them to be unfulfilled in any other use case.
That said, though I agree with this special case, I still strongly dislike that we need to handle substitution in this way. We had a few discussions in the ad hoc about alternatives to the current substitution mechanism. It has several deficiencies and confusions, and indeed this is one of its offensive consequences. (More on that below.)
Â
- And finally, you continue to treat substitution mapping and requirement fulfillment as though they are the same. These are fundamentally different features that should not be conflated.
I do not. I am merely pointing out one grammatical similarity. Again, if you agree that 2.9.2 is definitive, then you also must agree that the only difference between a node template being "selected" vs. "substituted" is simply in the directive used. That's all I'm saying here.
Also, in pointing out this similarity, I am playing along with the way substitution mapping works in TOSCA 1.3. Actually, I am unhappy by how similar substitution is to selection in this respect, exactly because I think they should be even more different. If you recall, my suggestion for a new mechanism for substitution (from inspired by Adam) involves a completely different approach that is based on node templates rather than node types (here's
the email). I specifically want to see TOSCA being able to do fuller composition using multiple nodes, and not just single-node substitution, which I think is too limited. But, though related, I think it's a separate discussion.