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

[Tal Liron <tliron@redhat.com>]

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

1. I would propose to make the fully qualified name of a type unique across all types.
1. 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:
1. 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.

Â

1. 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 }

Â

1. 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.

Â

1. 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.