[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
Comments inline /C From: Tal Liron <tliron@redhat.com> On Fri, Sep 13, 2019 at 7:07 AM Calin Curescu <calin.curescu@ericsson.com> wrote:
This is a very serious downside -- changes to the underlying types (e.g., if the capability type is imported) can introduce conflicts and force you to change names of properties, which can have cascading effects on orchestrations. In fact
it might not even be possible to change property names if the property names are enforced by orchestration. So I think it's crucial to have each of these things exist within their own namespace.
Seems entirely fine to me:
{ get_property: myNodeTemplateName, CAPABILITY, myCapabilityName, propertyInCapabilityName }
It is very useful to have two capabilities of the same type! The capability
definition is a kind of instantiation of the type, and each definition could refer to a different actual capability. Thing of something simple like a NetworkPort. You can have many ports on a node type, each with its own use. [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, â)
This would be very problematic because of ambivalently typed results. What isfthe property type is a list? So you would get a list back always and you wouldn't know if you should parse that list for multiple results, or if that result is
singular and is a of the list type. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]