Re: [tosca] Modeling node selection algorithms in TOSCA

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

Hi Tal,

 

I went through the document, and the âselectorâ is fine to be used when creating a relationship to a generic node that can implement such behaviour.

 

But, for the case when we have nodes already created in our system, maybe via another service template, where they have been already in service for some time, and we need to select them via those properties, there is where a node_filter using the extended condition syntax is useful (btw. itâs not an algorithm, itâs just filtering).

 

BR/Calin

 

 

From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Tuesday, 30 June 2020 at 20:14
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Modeling node selection algorithms in TOSCA

 

The discussion in the ad hoc today made me uncomfortable.

 

I think it's not a good idea for TOSCA to specify DSLs that model runtime algorithms. Doing so dictates the behavior of orchestrators and puts implementations in a difficult place: if they do not wish to support this feature (I definitely wouldn't, because it's extremely limited) they would have to be non-compliant. We can make it an optional feature (like we are suggesting, perhaps, to do with workflows), but ... I think we would be creating a complicated matrix of compatibility, which would be unfortunate.

 

I think there is a much better solution: model your not selection algorithm behavior using TOSCA data types. Do you like the proposed DSL? Great, I don't think we need to or should change TOSCA's syntax to support it.

 

Attached is a comprehensive example I created that mimics the proposed filter DSL using data types. It uses TOSCA 1.3 with no modification. It is heavily annotated with descriptions and comments.

 

You'll notice some subtle points where it is actually an improvement over the DSL. For example, specifying how many nodes you want selected, and what to do in case not enough nodes are available (do you want to provision the extra nodes?). My point here is also to show that the proposed DSL is a "lower common denominator" that is already insufficient even for the most trivial real world use cases.