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

Hello Tal, all,
 
I would like to jump in in relation to the capabilities occurrences. I don't think a node template can express the "requirement" that a capability must be used, i.e. if a topology template
contains a node template that has a capability which is not used to match a requirement, I wouldn't consider that as an error, even if the capability definition indicates an occurrences minimum value > 0.
 
If we read the description of the occurrences key name in the capability definition, it refers to the number of relationships "allowed" to be formed, not "required" to be formed.
 
For requirements it is of course different.
 
Best regards,
Arturo
 
 
 
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Sunday, June 7, 2020 7:20 PM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] "occurrences" 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.

On Mon, Jun 8, 2020 at 3:00 AM Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com > wrote: I would like to jump in in relation to the capabilities occurrences. I don't think a node template can express the "requirement" that a capability must be used, i.e. if a topology template contains a node template that has a capability which is not used to match a requirement, I wouldn't consider that as an error, even if the capability definition indicates an occurrences minimum value > 0. If we read the description of the occurrences key name in the capability definition, it refers to the number of relationships "allowed" to be formed, not "required" to be formed. I'm inclined to agree. The problem is that the "occurrences" keyword is of type range, so it does have a minimum. I am doing my best to make sense of the spec, even when it doesn't to me. :) So perhaps it should be called "maximumIncomingRelationships" or similar, and be integer, if that's the real intent. I really wish we can remove this keyword entirely, both in requirements and capabilities. If the intent is to create some sort of limits (upper or lower) for counting design-time relationships, it is unclear what the use case is. From my experience, most newcomers to TOSCA understand this as relating to runtime relationships. But a design-time relationship is not a runtime relationship. The line is drawn on the graph, but whether this translates to a deployment with one database connection, a pool of twenty round-robin SD-WAN links, a one-to-many directory to install software on all instances of a compute target, or even no runtime resource at all, etc. etc. etc. is beyond what this could do. The right way to do this, I think, already exists: properties, for both relationship types and capability types. They can be used to annotate whatever the "relationship" could, should, and would mean in the running service, all according to the specific domain you are modeling. To see this confusion in action, see my discussion on this issue opened in Puccini . I've been having this same conversation with people for years. :)