Re: [tosca] Proposal for requirement "occurrences"

[Tal Liron <tliron@redhat.com>]

On Fri, Feb 4, 2022 at 1:38 PM Chris Lauwers <lauwers@ubicity.com> wrote:

I call âget_propertyâ and âget_attributeâ on these target nodes all the time (e.g. if the target node is used to fulfill a dangling âdependencyâ requirement I use âget_property: [ SELF, dependency, â. ] â. While a selectable node can be used to force multiple relationships to the same target node, the same can be achieved using the appropriate node filters.

Â

As a side note, I very much dislike the ability to use get_attribute and get_attribute by specifying arbitrary nodes in the topology. I would much prefer if these functions could only be used to retrieve properties and attributes using graph traversal, i.e. starting at SELF).

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.

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.

Requirements are not âedgesâ. Relationships are. Requirements and capabilities are just the âportsâ on nodes that can be used for establishing relationships. Using dangling requirements, there will not be any âdanglingâ edges in any visualized graph.

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.