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