OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 ] }

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]