Hi Tal,
Your comments continue to show a difference in understanding of how requirements work:
- Whether a node filter is defined as part of a requirement definition or as part of the âselectableâ target node that fulfills the requirement, the behavior is exactly the same:
the orchestrator is expected to âselectâ a node from inventory that matches the desired node type and that has property values that satisfy the constraints specified in the node filter. As clearly stated in the spec, the âselectableâ node is just a convenience
method for specifying that requirements in multiple nodes must all be fulfilled using the same target node. In most if not all cases, the same result could be achieved by defining the appropriate node filters in the various requirements.
- You have a concern that the use of dangling requirements means that designers wonât know if their designers are complete or not. But this is exactly what tooling is for. A proper
validator will be able to list all the requirements that are left dangling and that must be fulfilled on Day 1. If you feel that there should be syntax to allow a designer to explicitly state âI intended to leave that requirement danglingâ, we can definitely
discuss that.
- Your âspecial caseâ treatment of dangling requirements in substituting templates is extremely problematic. It means that a topology template might be valid when it is used as a
substituting template, but not as a top-level template in its own right. We cannot allow semantics in the language that may or may not be correct depending on how templates are used. Whether a template is valid TOSCA should be a characteristic of the template,
not of how the template it is used.
- By the way, if forgot to point this out in my earlier email, but the Backup use case you presented earlier to motivate selectable nodes is invalid. The fact that you mark a node
as selectable means that it already exists, which implies that it already has all of its requirements fulfilled, including its Backup requirement. Defining different (and likely conflicting) requirements on selectable nodes must not be allowed.
We cannot afford to continue to have these open ended discussions. We need to clearly define what each of the features in TOSCA mean, write it down, have a vote, and move on. Iâll start a separate email thread for this purpose.
Thanks,
Chris
From: Tal Liron <tliron@redhat.com>
Sent: Wednesday, January 26, 2022 8:22 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Using pre-existing representations at runtime (without breaking the TOSCA graph)
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.
|