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

[Calin Curescu <calin.curescu@ericsson.com>]

Hi,

 

Tal, regarding your suggestions,

I agree with:

• as of TOSCA elements to include, we should add groups and policy (which should also support the SELF self-reference).
• Also inside a node, definitely we should have the ARTIFACT selector.

I am not convinced on:

• Changing the starting point. We already use the SELF to point to the same element, so I donât see any gain to change the existing notation, and make it always start in the SELF. There may still be situations when I want to get stuff from another node in the topology that I want to name directly.
• Regarding NODES in groups, I donât think itâs useful to navigate to the members, since they are added by their TOSCA element name anyway, so if I want to access a group member nodeâs properties, I can go directly to it.
• Regarding RELATIONSHIPS I think itâs better to use the REQUIREMENTS selector, and then go to RELATIONSHIP or CAPABILTY or NODE otherwise you lose the last two options.
• Now, you can get in your proposal to a TARGET of a requirement relationship (RELATIONSHIP, requirement_name, TARGET), but the SOURCE selector is useless since you are always already there.
• Moreover, if you use (RELATIONSHIP, requirement_name, TARGET, CAPABILITY, capability_name)  in your proposal this is not the same as (REQUIREMENT, requirement_name, CAPABILITY) in my proposal which takes you to the matched capability regardless of the capability name, which is what we really want.

Regarding the subsequent steps, if we don't continue traversing into a complex value I think itâs fine, since in a datatype we have a property of that datatype defined. So as long as the type match to the assigned property/parameter we can use it.

A further question is if we want to allow regexps to match fields inside complex types?

 

Now, regarding dealing with several occurrences of a requirement I would propose the following. Letâs assume that the index of a requirement with multiple occurrences is fixed and corresponds to the âorderâ of creation. By definition then, the order of creation is:

• First, the order of the requirement assignment as specified in the node template
• Subsequently the order in which the orchestrator has resolved the dangling requirements (if the orchestrator creates more occurrences than assigned in the requirement assignment)

So, we can add the optional selector (OCCURRENCE, <occurrence_index>) after the (REQUIREMENT, <requirement_name>) to select the right occurrence. If the OCCURRENCE selector is missing then we assume that we want the first occurrence.

 

Finally, we should also think of a get_properties function as Tal is proposing, but I would like to first talk about the multiple instances proposal as it will influence it.

 

 

Please find next an updated BNF based on the above:

 

get_property: [ <modelable_entity_name> <in_node_path> <property_name> <nested_property_key_index_regexp> ]

 

<modelable_entity_name> ::=  <node_template_name>, | 

                             <relationship_template_name>, |

                             <group_template_name>, |

                             <policy_template_name>, |

                             SELF, |

                             SOURCE, |

                             TARGET, 

 

<in_node_path> ::=  CAPABILTY, <capability_name>, |

                    ARTIFACT, <artifact_name>, |

                    REQUIREMENT, <requirement_name>, <occurrence_selection> CAPABILITY, |

                    REQUIREMENT, <requirement_name>, <occurrence_selection> NODE, <in_node_path> |

                    REQUIREMENT, <requirement_name>, <occurrence_selection> RELATIONSHIP, |

                    ââ

 

<occurrence_selection> ::=  OCCURRENCE, <occurrence_index>, |

                            ââ

                                                                                               

<nested_property_key_index_regexp> ::=  <property_name_regexp>,  <nested_property_key_index_regexp> |

                                        <key_regexp>,  <nested_property_key_index_regexp> |

                                        <index_regexp>,  <nested_property_key_index_regexp> |

                                        ââ

 

 

BR,

/Calin

 

 

From: <tosca@lists.oasis-open.org> on behalf of Chris Lauwers <lauwers@ubicity.com>
Date: Sunday, 22 September 2019 at 23:09
To: Tal Liron <tliron@redhat.com>, Calin Curescu <calin.curescu@ericsson.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17

 

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:
• 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. :)