Re: [tosca] Proposal for requirement "occurrences"

[Calin Curescu <calin.curescu@ericsson.com>]

Hi,

 

I donât see how one can specify any meaningful âdesign time graphâ without always using symbolic names as targets for requirements.

In this case all the representation graphs end up purely static, one cannot choose a target based on a filter on a property that is specified via an input.

 

I think this is a valid use case, but there are other use-cases that would like target nodes:

• âwithinâ the same service, but chosen by filtering on an input property (as identified by Paul in a previous mail and others)
• âoutsideâ the service to connect services together (as advertised by Matt several times in his TOSCA presentations)

In these use-cases one does not want to have a static âdesign time graphâ, the aim is to adapt.

 

There is nothing broken about these use-cases, they are so by design. As analogy, you cannot call a computer motherboard broken because it is missing the cpu, it is created so by design so people can stick different compatible CPUs in it later.

 

I also donât understand your use of a âtemplate graphâ. There is no such thing. The only graph is the ârepresentation graphâ. We have already agreed on this last year after many discussions.

As an analogy, the template of a brick is not the brick. It is used to create a brick, or a thousand of bricks. The house is built from bricks, not from templates.

 

get_property and get_attribute support both direct access (symbolic name) and graph traversal (starting from SELF or a specific node) and this is good so. The get_attribute for outputs is a moot point, one can use graph traversal to get an attribute value to a well-known (e.g. singleton node with a symbolic name) then transfer it to an output.

 

Tal, you want to restrict todayâs flexibility of requirements specification to express only static graphs fully fleshed out at design time, and I fully disagree with this.

BR/Calin

 

 

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

 

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

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.