Open lauwers opened 1 year ago
Groups with dynamically assigned members have been useful to me in other contexts. Perhaps the node_filter syntax could be used to define the group membership? TOSCA Traversal Path already complex; is there really a need to add further complexity? Are you suggesting getting a property of the group or getting a property of one or more members of the group?
Yes, I'm suggesting that the node_filter
syntax could be leveraged for this purpose. I probably confused things by using the word member_filter
rather than node_filter
. I envisioned that the syntax would be the same, but the purpose would be different.
After thinking about this more, perhaps we don't need extensions to the TOSCA Path
syntax, as long as we specify that the SELF
keyword refers to any node in the service topology that is a candidate for inclusion in the group. We may, however, need to introduce some additional functions. Using the example above, I could express dynamic group membership as follows:
groups:
tiny_compute:
members:
$and:
- $has_type: [ SELF, tosca:Compute ]
- $less_or_equal:
- $get_property: [ SELF, mem_size ]
- 4 GB
Of course, the syntax should continue to allow specifying members using the node template name as well.
OK the concept and syntax is clearer to me now. The example above couldn't be used in the V2 document as we no longer have tosca:Compute.
I have a use case where I need dynamic group membership. For example, I may need a group of all the
Compute
nodes with less than 4G of RAM (where the memory size is either provided as an input or obtained through a discovery process). With our current group syntax, the only way to specify group members is through node template names. What if instead we defined some type ofmember filter
that dynamically selects group members based on property values? Of course this may require extensions to ourTOSCA Path
syntax to identify group members insideget_property
functions. Any suggestions?