RE: [tosca] TOSCA property/attribute functions and entity name and type uniqueness

[Chris Lauwers <lauwers@ubicity.com>]

I think there are several shortcomings of the current âget_propertyâ syntax (or more specifically, in the syntax of the âpathâ argument list to the get_property intrinsic function):

 

1.       As Calin pointed out, there is no good way to get properties out of the target capability of a dangling requirement without also knowing the node type that contains this target capability.

2.       There is no way to get properties out of relationships

3.       There is no way to deal with multiple occurrences of the same entity (e.g. multiple requirements of the same name/type)

4.       I personally would like to see properties and attributes supported in interfaces (since this would allow per-interface state variables, which is necessary as soon as a node supports more than one interface). At that point, there will be a need to retrieve property and attribute values from interfaces as well.

 

Iâve long wanted to introduce a ToscaPath concept to formally define syntax for general-purpose traversal of a TOSCA topology graph. Iâll add this to the list of topics to discuss during our meetings.

 

Chris

 

 

From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Sent: Monday, September 16, 2019 7:42 AM
To: Tal Liron <tliron@redhat.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] TOSCA property/attribute functions and entity name and type uniqueness

 

Hi,

 

I agree with you. The problem comes from the matching being done on the capability type, not name.

 

I can only repeat the example below. NodeB calls the capability âRealâ nodeC calls it Deal. The âpropertyInCapabilityNameâ exists in both since itâs decided by the capability type not the capability name. But I cannot get to the property in both cases, since I must use the capability name in the get_property path.

 

It would be good if I could also use the capability type as an alternative to the name to solve this problem.

 

BR,

/Calin

 

From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Friday, 13 September 2019 at 19:56
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] TOSCA property/attribute functions and entity name and type uniqueness

 

On Fri, Sep 13, 2019 at 11:38 AM Calin Curescu <calin.curescu@ericsson.com> wrote:

[CC] Ok youâre right. What I wanted to say is that if I have a requirement in nodeA that matches to a capability type tosca.capability.RealDealCap and then I have nodeB that has capability Real and nodeC that has the capability Deal, both of type tosca.capability.RealDealCap, then both nodeB and nodeC are potential matches to the requirement, then how can I write a get_property function in nodeA that can extract property prop1 from within either the Real or the Deal, whichever match. I think this makes get_property useless if node type definitions name the capabilities of the same type differently. But I think I can drop the uniqueness requirement and further use a node_filter based on a specific property if itâs important to differentiate (e.g. eth1, eth2, eth3, â)

 

My understanding is that get_property uses the capability name, not the capability type name. And that name should be unique in the node type. E.g.:

 

MyNodeType:

  capabilities:

    myCapabilityName:

      type: MyCapabilityTypeName

 

{ get_property: [ myNodeTemplateName, CAPABILITY, myCapabilityName, propertyInCapabilityName ] }