You've decided to read a lot into 2.9. It's a discussion of the idea of abstract types in TOSCA and what could be done with them. But the language is suggestive and vague and its implications are not followed through. For example:
At
deployment time, the provider can then do a late binding and dynamically
allocate or assign the required hosting infrastructure and place software
components on top.
Sure, it can. But it might not. What then? How do we choose between "dynamically allocate" or "assign"? And what happens when it's no longer in use? Does TOSCA discuss garbage collection? And what if the user doesn't want the orchestrator to do any of this? The examples in 2.9.1 and 2.9.2 raise more questions than they answer. 2.9.2 at least insists on adding an explicit directive. I am following that spirit in proposing we add such a directive for 2.9.1.
Letâs please stop trying to remove functionality from the language that has been in there since v1.0. It has been very clear from the beginning that the purpose of requirements and capabilities is to allow composition
across service templates.
One of our goals for TOSCA 2.0 is to clarify vagueness. I made a concrete proposal in this email to clarify this vagueness. Using directives designers can specify exactly what they want to happen. This is very much in line with the spec.
Â
You continue to say this, and I have asked repeatedly without any answer: what exactly do you think cannot be validated in a design if you allow âdangling requirementsâ as per the 1.3 specification?
I have repeatedly answered. In this email: tools like Cloudnet and Puccini have to ignore requirements that are "dangling". These tools do not deploy and do not and cannot assume an inventory or platform for "selection", "allocation" or whatever. So, yes, strictly speaking ignoring a requirement makes it "valid", but it's passing the buck to deployment time and limits what is possible to validate in Day 0.
The 2.9.2 example is so, so much better for architects. It's the difference between these two designs:
2.9.1: "This is a motherboard. It has sockets for various things, like CPUs, RAM sticks, and drives." (single node with lines pointing out)
2.9.2: "This is a PC. It comprises a motherboard, a CPU, RAM sticks, and drives." (multiple nodes with lines between them)
The former is a spec for a motherboard (no topology). The latter is a design of a PC (with a topology).
Relatedly, it's very telling that the examples in 2.9 are explicitly about "hosting infrastructure"
and "software components on top" in the context of Simple
Profile's semantics, where the idea was that a virtual machine would be
spun up on demand (and garbage collected? when?). Infrastructure does indeed hold a special place in design. I can imagine that some application designers would not want to think about infrastructure at all. They just want to specify the "software components on top" and let the orchestrator take care of the rest. They don't want to see these "server" node templates in the spec. But, I think they are doing it wrong and would urge them to reconsider. Working in the cloud and being cloud native means accepting that "hosting infrastructure" is itself a software component. A good, complete cloud design would make it clear what the relationships are between ALL the components.
I raised the point (multiple times) that using 2.9.1 you can't specify that, say, three different software components should all run on a single server. You are leaving it up to the orchestrator to decide what is most optimal. But this is exactly the kind of decision that designers should be making. Only 2.9.2 lets you do so.
But, whatever, I'm willing to concede 2.9.1, though I will always call
it an anti-pattern and strongly recommend people not use it. You won
this one, Chris. I think it reduces the quality of TOSCA but I want to
move on.
What I insist now is that we turn the suggestive language in 2.9 into clear grammar. I made a concrete proposal to introduce directives.