What would be the use case where a topology needs to return an output for a node that it didnât create?
Maybe you would want to output the IP address of the "selected" node? It could be the input of another tool that would do something with that node (register it in DNS or other discovery system, deploy something else on it, etc.)
Â
You keep saying that, but you have yet to provide an example of what exactly cannot be validated when a topology contains dangling requirements.
I actually pressed "send" a bit too soon -- there is another solution. Instead of not storing the "dangling" relationship, a mock node template can be added to the database in order to complete the graph. It would just not be named. So you could analyze the graph that way. So, again, if we decide on implementing this feature we would need to discuss this in relation to node representations.
One problem is that this mocked node template might not have a node type. If you "danglingly" require just a capability type then you don't know what node type you will get. So, we'd have to introduce the concept of an un-typed node template, which doesn't feel good to me.
But even if we do know the node type, what are its properties? If there are required properties (without a default value) then their value is unknown.
(This problem exists in 2.9.2 as well, which is why I think we need to think more deeply about how the property filters relate to values. But at least there we have a typed node template and we can think about what to do with properties that have neither values nor constraints. As I said, 2.9.2 is the beginning of a conversation, not the end of it.)
We should also discuss what it means to filter properties of the target
node if its type is unknown. It seems to be currently possible.
All of these are challenges to analysis. We essentially introduce a new category of node template that at the end of the day is just unnecessary.