RE: [tosca] Proposal for requirement "occurrences"

[Chris Lauwers <lauwers@ubicity.com>]

 

 

From: Tal Liron <tliron@redhat.com>
Sent: Friday, February 4, 2022 11:24 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Proposal for requirement "occurrences"

 

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

It sounds like we all agree that fulfilling dangling requirements will always result in complete and valid node representation graphs (assuming suitable target nodes can be found) which in the end is all that matters.

 

Well, I also think that the design graph matters. A lot.

 

Tal is correct that target nodes used for dangling requirements will not have a corresponding node template in the service design, but I honestly donât understand why this is a problem. Is there anything that canât be validated, or that introduces ambiguity, or that increases the likelihood of errors? Or is this strictly an issue of esthetics and personal preference?

 

Without a node template, there's nothing the designer can do with that target node. The designer cannot relate that node to something else. The designer cannot relate other nodes to the same target. The designer cannot call "get_attribute" or "get_property" on it because it has no name (unless they are specifically trying to refer to it in the context of relationship values, which is the only place the TARGET keyword works).

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).

 

Moreover, there is no way to express this using standard (network) graphs. Think of the Cloudnet presentation from last week: in order to visualize such a "dangling" edge there would have to be a line coming out of one node pointing to ... nothing. Or, perhaps visually, it could be a box with a dotted line around it and a "n/a" for its name. So this might be the "aesthetic" awkwardness.

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.

 

But these graphs are more than aesthetics. I can see someone creating a TOSCA processor that uses a graph database to store all the topology templates. This can be very powerful for querying across a huge set of topologies, for example to find usage statistics, suggest optimizations, and even apply policies -- even if we enriched TOSCA's policy language, it would still only apply to one topology template, but a database of all of them can do more powerful things. A graph database does not have the concept of a line pointing nowhere. A broken graph here is not just a visual problem, it's a hurdle to a valid implementation of TOSCA.

I store all my graphs in a database. There are no technical issues with this. As a said earlier, dangling requirements are not âlines pointing nowhereâ.

 

Chris