Letâs put grammar issues aside for a minute, and try to get agreement on the core concept here. I donât think there is any question that requirements can be fulfilled at design time (Day 0). It sounds like we also agree that it is perfectly
valid in TOSCA to leave requirements unfulfilled with the goal of having those requirements fulfilled at deployment time (Day 1). Assuming we all agree, then we can turn to a discussion of the best syntax for Day 1 requirement fulfillment.
That's close but not quite good enough for me. :) I would say this:
I'm OK with runtime requirements only if the syntax is explicit and the grammatical and orchestration implications are fully understood. I wouldn't call it "perfectly valid". It's an anti-pattern that I will advise against using. I'm only open to compromising here in order to move us forward. But also it's essential that before we do so we accept the example at 2.9.2 as definitive, which also means we would also have to spec it out properly.
I do agree with you that TOSCA has always hinted at runtime requirements. Way back years ago when I made my TOSCA tutorial (for 1.0) it was there in the spec as suggestive little wordings, but I could not see how it could be implemented coherently. For example, in TOSCA 1.0 this is how node_filter for node templates was described:
The optional filter definition that TOSCA orchestrators
would use to select the correct target node. This keyname is only valid if
the directive has the value of âselectableâ set.
Note that there is no mention of "at runtime" here, and example 2.9.2 is the only place where it is used. And what does "target node" mean here? Target of what? This implies that it relates somehow to the requirements of this node template. Anyway, so little here to build upon.
As for requirement node_filter, it's even less clear:
The optional filter definition that TOSCA orchestrators or
providers would use to select a type-compatible target node that can
fulfill the associated abstract requirement at runtime.
Â
And that little hint, "at runtime", was pretty much all the explanation we got. But this hint created far more questions than it answered. Nowhere does it say here that this "type-compatible target node" could be somewhere else, other in the topology template. The word "dangling" does not appear. Could "at runtime" mean at the Day 1 moment of deployment, in reference to variability due to get_input, as we saw in my previous email? The target word used here is "node" rather than "node template",
which is ... what exactly? We had no concept then of node
representations. Nowhere does it say here that this "node" might live in an external inventory or that a node representation can be created on-the-fly for an existing (pooled?) real-world node instance.
You've found answers to these questions that made sense to you and have built them into a complete feature. I'm uncomfortable with many of the assumptions behind these answers. From my perspective, 2.9.2 solved the problem of runtime selection completely and this "at runtime" hint was a confusing distraction (there are many such confusing distractions in the spec). Actually, I've never even needed to use a "select" directive. (In TOSCA 1.0, section 2.9.2 actually does not use that directive, it's added in later versions of the spec).
The matter of whether a node template is something to be "created" (provisioned, removed from a pool, instantiated, etc.) or "selected" by the orchestrator is just ... not that interesting for TOSCA. It's a decision that's ultimately made by an orchestrator that takes into account many complicated factors having to do with its inventories, platform specifics, optimization algorithms, etc. At best a designer can provide policies (or metadata hints) that can direct or constrain the orchestrator's eventual decision. An example of such a policy is: this server cannot be shared with other services. That means that the orchestrator can either provision a new VM or use an unused one from a pool, but it absolutely cannot "select" one if it's already being used by another service, even if it matches the requirements.
We've come a long way since TOSCA 1.0. We now have a clear and agreed-upon "mental model" for a TOSCA processor. With that, I think, it's time to expand the model in order to consider what "runtime" could really mean for TOSCA. I would start with these questions:
- Can a service access node representations created by other services? (this is a question for 2.9.2, not just for "dangling" requirements)
- What would be the rules for accessing them? (security considerations).
- Do node representations only originate in TOSCA, or can an orchestrator create node representations from pre-existing runtime instances? When and how should that happen? How would this relate to the access rules of #2?
Again, the best starting point for me is 2.9.2.