RE: [tosca-comment] Identifiers in reference to multiplicity discussions

[Chris Lauwers <lauwers@ubicity.com>]

Independent of which lifecycle operations youâre defining, a âunique IDâ attribute for a node will not be allocated until after communication with the external entity that allocates the ID. Such communication cannot happen until after the service topology representation has been fully resolved (i.e. requirements allocated, substitutions performed, etc.) Specifically, this means that requirement fulfilment will not have the benefit of having a valid âunique IDâ attribute in the node representations, which makes it all but impossible to use attributes as useful unique IDs for purposes of TOSCA processing.

 

Thanks,

 

Chris

 

 

From: Tal Liron <tliron@redhat.com>
Sent: Sunday, March 14, 2021 8:48 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Paul Jordan <paul.m.jordan@outlook.com>; tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] Identifiers in reference to multiplicity discussions

 

On Fri, Mar 12, 2021 at 5:51 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Using property or attribute values as unique IDs for node representations is challenging, in my opinion:

 

• If a property value is used, then the burden falls onto the service designer to define that property and assign values to it.
• If an attribute value is used, then that value is not available until after the external instances/implementations in the real world have been created. A TOSCA orchestrator performs a lot of actions before this happens (requirement fulfillment, substitution, composition, etc.) and the orchestrator would not have access to attribute-based unique IDs for these activities.

Re: attributes. This is exactly why we agreed that "node representations" sit somewhere in between the TOSCA processor and the runtime environment. "Full" processing indeed requires the get_attribute function to be callable.

 

The function, in terms of TOSCA grammar, does not limit its scope to some kind of lifecycle phase, especially now that we're removed the Simple Profile and any specific normative lifecycle from consideration. Grammatically, every call to get_attribute for the same attribute can return a different value. This means that get_attribute *could* return a useful value from a node representation management system that indeed uses a specific ID scheme (namespaces, GUIDed, scoped, etc.).TOSCA attributes (which are typed) could be used to model these IDs and allow them to be used, as values, in interface/operation/etc design considerations.

 

In fact, I'm sure that this is a common case for modeling systems. Even the Simple Profile had a "name" attribute that implied some kind of runtime identification.