[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] "occurrences" in requirement assignments
Hi Tal, More inline. But, please take also a look at one of the latest drafts in the requirements/capabilities definition/assignments sections.
I think it is carefully explained there. Moreover, all the edits have been discussed and accepted in the WG during the long discussions that we had. I believe that until 2.0 the exact definition were not clear, and we have now the opportunity to clarify them in a manner
that will increase their usefulness. BR/C From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com> On Thu, Jun 4, 2020 at 11:41 AM Calin Curescu <calin.curescu@ericsson.com> wrote:
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] The
requirement occurrences in the type definition is a range and has been so in all versions. It means that you can defines y assignments that are in the [y, z] range. The
requirement occurrences in the requirement assignments has been defined as a integer now in 2.0. This has nothing to do with the
requirement occurrences in the type definition. Please also note that refinements only apply to definitions in the a type (always) and are totally orthogonal to assignment definitions. Example: in the type: requirements: - demand: â occurrences: [3, 7] in the req. assignment: requirements: â - demand: node: target1 - demand: node_filter: â occurrences: 3 - demand: node: target8 As you see, in the assignment we assigned 5 occurrences to requirement demand: 1+3+1 = 5, which is ok since 5 is in the
[3, 7] interval which is the constraint defined in the type. The occurrences in the assignment are just syntactic shortcuts of not writing the node_filter 3 times if itâs the same.
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.) [CC] Agree 100% with your statement. This is not a discussion on the instance model here, itâs a design discussion. In the
type you give an interval as type designer, in the assignment you assign the number of supported occurrences (which has to be in that interval to be valid). 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. [CC] see above. 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. [CC] There was a discussion in the on this, and we could not find a meaningful reason for constraining the lower boundary
of occurrences of a capability, i.e. if an entity is capable to give you 4 apples, it is capable to give you also 1 or zero. Besides, you could not use that across service templates since not all service templates are instantiated at the same time, and it
would give an error. Furthermore, within the same template, you would make anyway a design decision which node will have relationships to which nodes. [CC] can you give me an example of where do you think you need to return 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]