Hi Tal, thanks for the detailed write-up. Iâll need more time to digest the entire message, but I wanted to respond specifically about your comments about requirements, since it appears we have a fundamental difference of opinion here:
I hope you will have time to digest more. :D
I agree with all your points in essence, but am looking at it differently. To an extent, I am saying that all requirements are really "dangling", because they are really requirements for node templates rather than for node instances. I am arguing that the node template is a good way to express the parameters of the requirement. That "inventory" of nodes you mentioned -- well, a node template is exactly how you can tell the orchestrator what should be in that inventory.
Or let's put it another way: imagine we didn't have "requirements" and only, as you put it, "explicit relationships". That would actually still be fine in my view, and still allow for the exact same "dangling". Let's image we had such a grammar:
node_templates:
 my_app:
  relationships:
  - host: my_server
 my_server:
ÂÂÂ properties:
ÂÂÂÂÂ arch: x86
ÂÂÂÂÂ ram: 16 gb
I do not read this as "hey orchestrator, provision one server for me and install an app on it". Actually, I'm not even sure what that would mean -- "my_server" is a template for nodes, but how many nodes? I don't know. And how many instances of the app need to be installed? I don't know, maybe it's a Kubernetes pod with 50 containers in it. I don't really care in terms of designing my topology. Those numbers depend on scaling, redundancy policies, and cloud-native decisions. When designing topologies for Kubernetes you actually might relinquish control over numbers of instances entirely, and then configure certain controllers to manage those numbers for you. Even numbers of "relationships" could be controlled: imagine the relationship is a configured network connection to a database server. For redundancy perhaps two such connections would be formed, each to a different container instance in a pod. So I read this design this way: "hey orchestrator, when and if you provision or schedule servers, and also provision or schedule app instances, then those specific app instances should be installed on those specific servers". The way in which this happens might be quite complex indeed. In other words: I'm desigining a relationship, not giving a command to create a relationship.
In yet other words: A node template represents a potential for actual nodes, while a "relationship" -- even when entirely explicit, as in this case! -- represents a potential for a actual relationships between those actual nodes. This grammar, to me, represents exactly that "dangling" aspect you mention.
Am I arguing that we should remove the "requirements" grammar, then? Well, I do think it's nice for designers: it automates some design work, and also gives some power for creating node types with both flexibility and strong validation. Since TOSCA 1.0 I've found it quite useful. But it's useful only as long as we understand that it's an entirely design-time grammar. But if it helps reduce confusion -- and there's always been plenty of confusion regarding the "requirements-and-capabilities" feature -- then, yes, let's throw away that grammar and make all relationships explicit. Cloudify does that and doesn't seem less usable than TOSCA for its supported use cases.