OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only
Expand all | Collapse all

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

  • 1.  Re: [tosca] TOSCA property/attribute functions and entity name and type uniqueness

    Posted 09-13-2019 16:38




    Comments inline
    /C
     

    From: Tal Liron <tliron@redhat.com>
    Date: Friday, 13 September 2019 at 17:41
    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 7:07 AM Calin Curescu < calin.curescu@ericsson.com > wrote:




    In requirements in several places we can have either Capability types or Node types, so there is a problem if we have a node type and a capability type with the same name




    I would propose to make the fully qualified name of a type unique across all types.




    The get_property and get_attribute may refer into the capability and requirements hierarchy. But there is no way to distinguish if a name in the path is a requirement or a capability or a property/attribute. There are 3 ways to solve this:



    requirements and capabilities and properties/attributes names must be unique within a node definition. This could be a problem if I derive a node and want to add a new capability with a certain name but I cannot since it s occupied by a previously
    defined property.





    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.


     







    We change the get_property and get_attribute function to specify the entity type before the name. i.e. introduce the PROPERTY or CAPABILITY or REQUIREMENT keyword in the path





    Seems entirely fine to me:
    { get_property: myNodeTemplateName, CAPABILITY, myCapabilityName, propertyInCapabilityName }


     







    We can use alternatively the fully qualified capability type name for a capability instead the
    capability name . I think this to be the best option. I mean if I have a requirement where I specify the capability type to match, I might not even know the capability name in the matched node. So this referencing would be much more useful. This would
    of course mean that we should not be able to define two capabilities of the same type in a certain node type, which is ok (capabilities should be qualitative not quantitative).





    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, )







    It is not specified what the get_property will do in case we have a requirement with a multiple occurrences. I propose in this case to return a list containing all such properties in all instances. But we should revisit this once e defined
    how to handle multiplicity.




    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.









  • 2.  Re: [tosca] TOSCA property/attribute functions and entity name and type uniqueness

    Posted 09-13-2019 17:56
    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 ] }