RE: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal,

 

A couple of comments:

 

-          I donât believe we can do away with SELF unless we also do away with the ability to specify an arbitrary node in the (containing) topology, as in:

o   get_property: { <node_name>, <property_name>]

-          When discussing your proposal to return sets of values for intrinsic functions, we should start with a discussion about what these functions are intended to be used for. In my implementation, the goal of âget_propertyâ is to uniquely identify one single value that is passed on as an input to an interface operation or that is to be used in condition expressions in policies. Changing from a single value to a set would completely break this. Do you have a different use in mind?

-          There are other âintrinsicâ functions in the current spec for which I donât understand the intended us. Specifically, what would we use âget_nodes_of_typeâ for?

 

Thanks,

 

Chris

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Tal Liron
Sent: Friday, September 20, 2019 9:53 AM
To: Calin Curescu
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17

 

Thanks Calin,

 

I'd like to propose some modifications of your suggestion and present it a bit differently. Also let's keep in mind that the same notation would apply to get_attribute.

 

I'd also suggest that we need a way to support multiplicity of results. I have some ideas about that.

 

This is going to be purposely verbose because I want to take you along for the traversal ride! But I think in the end it's quite intuitive.

 

STARTING ENTITY

 

Since we're moving to a traversal notation, then I think we can do away with "SELF". It should be assumed that we start with ego. Specifically, though, there are a few possibilities for the starting point entity:

1. Node instance
2. Group instance
3. Policy instance
4. Relationship instance

(The "instance" is very important here when we think of get_attribute, because while properties are the same across all instances, attributes are not.)

 

We determine which entity according to where the function call is located. Note that this location applies to both "templates" (node_templates, groups, policies, relationship_templates) and to types (node_type, group_type, etc.), such as the "default" keyword in the type.

1. If the function call is located in a node property or attribute then the starting point would be that node.
2. If the function call is located in a capability property or attribute or artifact property then the starting point would be the containing node.
3. If the function call is located in a group property or attribute then the starting point would be that group.
4. If the function call is located in a policy property then the starting point would be that policy.
5. If the function call is located in a relationship property or attribute then the starting point would be that relationship.
6. Because interfaces can exist in either nodes or relationships (not groups since TOSCA 1.3), if the function call an interface or operation input or a notification output it would depend on where the interface exists. (Side note: This would also affect the use of "SELF" keyword for the attribute mapping of notification outputs.)

FIRST STEP

 

OK, so that's our starting point. We then have a few options for the first step. I do want to point out that all subsequent steps might traverse us to a set of instances rather than a single instance. I'll explain more about that when we get there.

 

For all entities:

• <property name>: This would traverse us to the property value in the current entity. This could be the final step.

If we are in a node instance, we also have these options:

1. CAPABILITY, <capability name>: This would traverse us to that capability. This cannot be the final step.
2. ARTIFACT, <artifact name>: This would traverse us to that artifact. This cannot be the final step.
3. RELATIONSHIPS, <requirement name>: This would traverse us to the set of relationships instantiated for that requirement name. (Remember, the one requirement name in the node type can be specified several times in the node template, limited by the "occurrences" keyword.) From now on traversal is as a set. This cannot be the final step.

If we are in a group or policy instance, we also have this option:

• NODES: This would traverse us to the set of members of the group or targets of the policy (nodes). From now on traversal is as a set. This cannot be the final step.

If we are in a relationship instance, we also have these options:

1. SOURCE: This would traverse us to the source node. This cannot be the final step.
2. TARGET: This would traverse us to the target node. This cannot be the final step.

Also note that if we are traversing as a set, the result of the get_property functional call will be an array of results. This doesn't matter if there is one result, many results, or no results (empty array).

 

SUBSEQUENT STEPS

 

OK, so now we have a few additional options.

 

The previous step may have traversed us into a property (or attribute in the case of get_attribute) value. If that's the case we can stop here. Or, if the value is complex, we can continue moving deeper into the value's structure in subsequent steps. So we can use:

1. Field names (the "properties" of a complex data type)
2. Map keys
3. List index (an unsigned integer)

(Side note: What happens if we don't continue traversing into a complex value? Would the entire value be returned? The format for that would differ per parser/orchestrator implementation, which would be OK. But this is something that the spec does not discuss.)

 

We can also use the various keywords mentioned in the first step to continue traversing, according to what kind of entity we are at right now: CAPABILITY, ARTIFACT, RELATIONSHIPS, NODES, SOURCE, TARGET.

 

However, it's important to understand that if we are traversing as a set, there is no turning back to traversing a single path. All subsequent steps would be sets.

 

For example, let's consider a simple example of traversing as a set, where the starting point is a group instance:

 

get_property: [ NODE, CAPABILITY, mycap, myprop ]

 

We might have 10 node templates in the group, so we are traversing as a set. And then we are gathering all the capabilities named "mycap" from all of those nodes. And finally we are gathering all capability properties name "myprop" from all those node instance capabilities.

 

A more complex example from the same starting point of the group instance:

 

get_property: [ NODE, RELATIONSHIPS, myreq, TARGET, CAPABILITY, mycap, myprop, mylist, 1 ]

 

The 10 node templates in the group would have 10 or more or less relationships named "myreq" (it could be less if the "occurrences" range was [0,UNBOUNDED] and the requirement was not specified in one of the node templates), so step #2 might increase/decrease the size of the set as we move to a set of relationships. Step #3 would move us to the relationship targets, but since each relationship has one target the size of the set would be the same as in step #2, now comprising nodes again. Step #4 moves us to capabilities, again the same size (there's only one capability of that name per node). And finally we'll get the result as an array of all those capability properties, and so on.

 

DISCUSSION OF IMPLICATIONS

 

The move from traversing singularly to traversing as a set is subtle. Because it amounts to a different kind of function call result, it may make sense to break it into two functions to increase clarity:

1. get_properties: This is for traversal as sets. The assumption is that we always start as a set (with one member, our starting point in instance) and always return an array of values.
2. get_property: This is for singular traversal and will always return a single value. This means that any traversal keyword that would move us to traversing as a set would not be allowed. Looking above, this is exactly two keywords: RELATIONSHIPS and NODES. (Those are the two keywords expressed in plural form, to emphasize the fact that they move us to a set.)

Is it too complicated to chose between two functions? A few other options:

 

We could possibly just have the plural function, get_properties. The advantage is that the "traversal as a set" distinction doesn't have to be considered. The problem is that in some situations we really do expect and need a single result, even if there are many potential results.

 

So another thing we can do is keep both get_properties and get_property, the former returning an array and the latter returning a single result. However, we do not restrict the latter from traversing sets (RELATIONSHIPS and NODES keywords). Instead, we specify that if there are multiple results then an arbitrary one is selected. This could "just work" as expected in some trivial situation, but the indeterminacy is frightening.

 

Finally, let's look at get_attribute. If you've been following the discussion until now you'll realize that we should always traverse as a set. The reason is that even if we stop at a node template entity, we would have to gather the attributes from all instances. So for consistency there should be a get_attributes function but no get_attribute function, because we should always expect multiple results.

 

Another interesting implication: if we use get_attribute where the starting point is a policy instance, then we have to traverse to somewhere else. The reason is simple: nodes, groups, and relationships all have attributes, but policies do not.

 

I have some more thoughts about notation but will stop here, because I think there's quite enough to discuss.

 

In case we do want to discuss in meeting, please note that I am unable to attend the meeting next week on Sep 24! But you can go on without me. :)