[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Proposal for requirement "occurrences"
We discussed that problem in some depth. It's not clear what would happen if there are several relationships created for the requirement named "dependency" in terms of traversal. Whatever rule we choose (should
the result be a list of all results?) there's still no clear way to deterministically refer to a specific target. Yes, but that problem exists independently of dangling requirements. We have presented several proposals for fixing this problem, all
of which you have rejected also. BTW, the common use case of using "get_attribute" for the topology outputs won't work without referring to a specific node template name. There is no SELF in that context. What would be the use case where a topology needs to return an output for a node that it didnât create?
Sure, you can just pretend that "dangling" requirements are not in the design graph and not store them in your database. Indeed that is how I suggest we "solve" this problem (it's the only way, really). But it's
a sad solution: you end up with a design graph that doesn't match the deployment graph. This important aspect of the design -- the fact that there is supposed to be an edge to another vertex -- is simply not there. This makes any kind of graph analysis at
the design phase necessarily incomplete. "Dangling" forces the designer to set up a runtime environment with an orchestrator and fully deploy the template in order to truly validate it. Day 0 has never been so expensive. You keep saying that, but you have yet to provide an example of what exactly cannot be validated when a topology contains dangling requirements. Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]