OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Hi Tal,
Tried to explain my understanding, does it make sense?
Please see inline.
BR/C
 

From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Thursday, 28 May 2020 at 19:45
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] "occurrences" in requirement assignments


 



This keyword was added in TOSCA 1.3, in section 3.8.2.1.


 


We've discussed it several times in the ad hoc meetings, in relation to ... many topics, most notably the instance model. But it remains for me a feature I simply cannot implement in Puccini.


 


In Puccini, "occurrences" in requirement definitions
are interpreted to mean exactly how many times the requirement can/must be assigned in the node template, with the additional understanding that the sequenced list notation is there exactly in order to allow multiple assignments. I think this interpretation
makes sense in many practical ways. Note that this has nothing to do with the instance model: this is all about TOSCA grammar and how many times you are allowed to specify something. (Puccini uses a similar design-time interpretation for "occurrences" in capabilities,
for which it specifies how many times the capability can/must satisfy a requirement.)
[CC] fully agree.


 


But, with that understanding, I have no idea what "occurrences" could mean in the requirement
assignment . It seems the thinking here is that "occurrences" has something to do with the instance model. So, for now, Puccini parses this keyword as proper syntax, but never does anything with it.
[CC] For requirements: In the assignment the occurrences its s only relevant if we use node-filters to connect to several
nodes. Then if the same node filter should be reused, it s easier to just put occurrences to 3 instead of repeating 3 times the requirement assignment
[CC] For capabilities: It s the final decision of how many connections to that capability are allowed. In the type we can
specify a range, but in the end a final number needs to be chosen. Note, that this does not require a fixed number of connections, but fixes the maximum number of connections that can be supported. Of course, if no assignment is provided, the orchestrator
could automatically choose (say the max of the interval from the type).


 


Indeed, for TOSCA 2.0 I've suggested several times that we should remove this keyword everywhere. If it's a design-time feature then it's rather narrow and hard to imagine as being very useful (and should probably be renamed to "assignments").
If it's a runtime feature, referring to the instance model, well that's a whole can of worms that we've discussed at length. I'll likely continue to argue that TOSCA should not have an opinion on the structure, and if it does then a simple counting of "how
many runtime relationships" seems woefully insufficient.


 


But, I do want to open this up more on the email list, perhaps someone can shed some light on the confusion? Also, what do you think I should do in Puccini if it's impossible to "support" this keyword in requirement assignments?

On Thu, Jun 4, 2020 at 11:41 AM Calin Curescu < calin.curescu@ericsson.com > wrote: But, with that understanding, I have no idea what "occurrences" could mean in the requirement assignment . It seems the thinking here is that "occurrences" has something to do with the instance model. So, for now, Puccini parses this keyword as proper syntax, but never does anything with it. [CC] For requirements: In the assignment the occurrences its s only relevant if we use node-filters to connect to several nodes. Then if the same node filter should be reused, it s easier to just put occurrences to 3 instead of repeating 3 times the requirement assignment This could make sense, but remember that it's more complicated because it's a range. What would [ 4, 6 ] mean? Let's say that there 10 possible matches. Would we gobble up the top of our range, 6 connections? Or do we emit an error about there being too many possible matches? And what if there are 2 possible matches? Does that mean an error, too, because we haven't reached our minimum? (By the way, it's not just an aspect of node filters. Even the most minimal requirement, e.g. specified via a capability type name, could have >1 matches.) This could possibly make sense, though it still seems convoluted to me. One thing is for sure is that "occurrences" in requirement definitions are entirely different from "occurrences" in requirement assignment. The latter cannot be a refinement of the former. So if we decide to keep this in 2.0 (PLEASE LET'S NOT) then we need to do a lot more to clarify the meaning of both keywords and remove any refinement rules. [CC] For capabilities: It s the final decision of how many connections to that capability are allowed. In the type we can specify a range, but in the end a final number needs to be chosen. Note, that this does not require a fixed number of connections, but fixes the maximum number of connections that can be supported. Of course, if no assignment is provided, the orchestrator could automatically choose (say the max of the interval from the type). A few things to say about this: 1) I don't see any of this as an "orchestrator" issue, because it's a grammatical feature, all in design-time. We again are going back to discussing the instance model. :) I interpret capability "occurrences" to be about counting how many design requirements can be "satisfied" by connecting to this capability. (Similar to how you described "occurrences" for requirement assignments.) 2) There's less confusion regarding capabilities, because capabilities are syntactically maps, so there is only ever one capability of that name in both the node type and the node template. Requirements are far more complicated because they are syntactically sequenced lists, both in the node type and the node template. That's why "counting" could have multiple meanings. 3) For capabilities, I do treat the lower bound as a minimum. E.g. if your capability "occurrences" is [ 2, 3 ] but you only have 1 incoming requirement then it is indeed an error. All this means is that in Puccini the requirement satisfying algorithm is a bit complex ( see the source code here ). When choosing a node to match a requirement it tries to satisfy those capabilities that have minimums first , to make sure that they are "filled up". Once they all have their minimums it is possible to choose any arbitrary capability, up to the maximum specified by the "occurrences" range. When all maximums are reached, the requirement cannot be satisfied and you get an error.