lauwers
commented
2 years ago I agree with Peter. "Dangling requirements" are specific to service templates only. When the orchestrator creates a service representation based on the template, all dangling requirements must be fulfilled. The result is one single representation graph.
In my world, I don't have any "Dangling requirements problem", but my approach is radical:
Instead of regarding every TOSCA service as an isolated "island" with its own node graph, I have one and only one node graph, that may or may not consist of disjoint parts that may be defined by different TOSCA template deployments. This means that TOSCA templates are allowed to create a part of the big-picture node graph, and what would appear to be "dangling" in narrow optics is not at all dangling when viewed this way.
I think what I do is actually exactly reflecting the semantics of "dangling requirements" - that TOSCA services may draw in nodes in the bigger node graph.
In practice we use this a lot. Consider deploying topologies in an environment where there needs to be virtual routers configured as Route Reflectors. The Route Reflectors are "owned" by the service provider, and can be shared by some number of users. So a Route Reflector will be a node in multiple topologies where each user only sees their own topology, but where the Service Provider sees the bigger picture where the nodes are shared. So the Service Provider sees the true picture of the node graph.
What the individual users see is only an abstraction of the node graph, where the Route Reflector nodes are either not seen at all, or are only viewed through the slice allocated to the users. Of course our language has mechanisms for controlling node graph visibility to create that abstraction.
What this also means that our Service Catalog - consisting of the available templates is really aggregating those templates together into one huge template that covers the full node graph. This allows us to do the complete template checking that @tliron so rightly points out cannot be done if templates are treated as isolated, while still allowing dangling requirements.
This works for us, because our language is literally infinitely more compact and easier to compose than TOSCA. A few, relatively small templates in our language can define an infinity of TOSCA templates. Working the other way, a TOSCA language template is translated to a small selection within that hyper-topology space. This makes day 2 transformations easier to handle, because two TOSCA templates that appear to be completely different topologies from TOSCA perspective become part of the same hyper-topology space - allowing us to easily define the transformations from one to the other.