[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Capability assignments in node template
|
Comments inline From: Calin Curescu [mailto:calin.curescu@ericsson.com]
I think the ârefinement rulesâ we are adopting will cover Arturoâs concerns (i.e. only refined types will do). Chris, regarding the two cases below, I realized that was what made me confused with assignments in the first place. Can we play with âoccurencesâ keyword in the assignment? Or is each assignment for one and only
one occurrence? See example below:
my_compute
type: tosca.node.Compute
â
requirements:
- local_storage: my_storage_A
- local_storage:
node_filter:
properties:
â
capabilities:
â
occurrences: [0,2]
- local_storage: my_storage_B
- local_storage:
node_filter:
properties:
â
capabilities:
â,
- local_storage: my_storage_C
So:
Â
Is the above allowed or are the âspecific assignmentâ and âdangling requirementâ mutually exclusive? Yes, in my opinion. In a nod template, a requirement is either: -
A requirement assignment -
Or a refinement of the requirement definition in the node type (with optionally also a node filter specified)
Â
Obviously, âspecific assignmentâ can be used only for one occurrence, but can we use the âdangling requirementâ to cover several occurrences? That is a good question. Technically, the answer is yes but this brings up the question youâve raised before: why would the orchestrator use anything more than the minimum of the range?
Â
Now, can we specify a range of âdangling requirementsâ? Not sure what you mean by this. How would this be different from a dangling requirement with its own range (i.e. occurrences)?
Â
If so, and we want to later use the get_property function through this node and this requirement, how will I know to access the requirement that has been assigned to âmy_storage_Bâ. What I want to say:
o
if the previous âdangling requirementâ resolves to two relationships then my_storage_B will be mapped to the 4th occurrence of local_storage,
o
if the previous âdangling requirementâ resolves to zero relationships then my_storage_B will be mapped to the 2nd occurrence of local_storage This makes it impossible to access the right requirement through the get_property function since the index of the occurrences will be fixed only after the instance model has been set up, and relationships resolved
and not during template parsing. Yes, this problem is similar to the substitution mapping problem weâve talked about before. This problem would also exists if we allow multiple nodes to be instantiated from the same node template (a use case weâve
also talked about before). Given this, I would specifically disallow using the âoccurrencesâ keyword in the assignment of the requirements. Now, I am not even sure that the occurrences keyword was supposed to be used in the requirements assignments.
They do not appear in the keynames definition in section 3.8.2.1 but appear in the example of section 3.8.2.2.2. I thought the former was an oversight but not sure anymore. At the very least, we should make the spec consistent Given the above then each list entry should only specify one occurrence.
Are you suggesting that is multiple occurrences need to be specified in a node template, this would be done by creating a list of requirements that all have the same name, even when each of these requirements are
dangling? But then this will amount to:
Â
fixing the amount of occurrences in the assignment by the length of the list (even if the range is unbounded in the requirement definition)
Â
if no assignments are given in the list, we have 0 (zero) occurrences specified. BR, /Calin Chris From: Chris Lauwers <lauwers@ubicity.com> With respect to requirement assignments: There are really two completely different use cases for requirement assignments:
Please let me know if any of this is not clear. Thanks, Chris From: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>
Hi all, For the capability assignment, I am in favour of introducing the support of the occurrences keyname in the node template. This would still leave us with the question what to do in SOL001, which is based on TOSCA YAML 1.2. We could make here also an exception and allow the use of occurrences already.
For the issue about the requirement assignment that Calin has spotted and is well brought up here, I donât know what was the original intention to allow indicating capability type, node type and relationship type in
the requirement assignment (I do understand capability definition, node template and relationship template) but I guess it was not to allow to change these with respect to what is specified in the requirement definition in the node type definition. As Calin
said, this would change the requirement. Was the intention to allow them in case node type or relationship type were not defined in the requirement definition? I am also in favour to clarify that the requirement assignment should not indicate a capability, node or relationship type different with those indicated in the requirement definition, if any. Best regards, Arturo From: Calin Curescu
Hi, Actually there is a larger set of inconsistencies here. I will try to unravel it. If we look at the node type definition (section 3.7.9) , one can specify a map of âcapability definitionsâ and ârequirement definitionsâ. If we look at the node template definition (section 3.8.3), one can specify a map
of âcapability assignmentsâ and ârequirement assignmentsâ. Nevertheless if we look at the capabilities definitions (section 3.7.2) and requirements definition (section 3.7.3) both state (in the first paragraph) that they can be used in node types and in node templates.
Â
At least for capabilities, it would be wrong to have definitions in the node template since they contain property definitions, which cannot appear in a node template, (I have not seen that in any example, that
a node template can introduce a property (definition or assignment) that is not previously defined in its node type).
Â
We could allow for requirements definitions in the node template (as requirements do not have properties or attributes) but this would be asymmetric to capability definitions. Moreover, if we look at requirements assignments (section 3.8.2) that are specified in the node template, we see that at assignment time we can override any keynames already specified in the requirements definition (in the
node type). So basically I can change the node type, the required capability, etc. The question is then: is the node template where we do this still of the same type since its requirements are soo different from what is defined in its Node Type? Now as per Chris suggestion in the previous mail, if we constraint the capability assignment to be within the limits of the capability definition, should we not do the same thing for requirements? BR, /Calin From:
Chris Lauwers <lauwers@ubicity.com> Of course, to be valid the range specified in the âoccurrencesâ keyname in a capability assignment must fall within the range specified in the âoccurrencesâ keyname in the corresponding capability type. Chris From: Chris Lauwers
Yes. My apologies Arturo, I spoke too soon. I had incorrectly assumed that capability assignments support the âoccurrencesâ keyname. This is another inconsistency in the spec, since requirement assignments do support this
keyname (see Section 3.8.2.2.2). Unless anyone objects, weâll fix this in the next revision of the 1.3 spec. Chris From: Lishitao <lishitao@huawei.com>
Hi Arturo and Calin I see your point. I agree that the occurrence should be changeable in the node template level.
Regards shitao åää:
Calin Curescu [mailto:calin.curescu@ericsson.com]
Hi Arturo, You bring up a relevant problem: âHow can one specify at template specification time the number of occurrences of a particular capability of a certain capability type ?â. Right now, the
occurrences can be specified at Capability Type creation time, but cannot be changed during capability assignment in the node template (i.e. they are a type characteristic). This is also asymmetrical to the ârequirementsâ since requirements can be directly defined in the node template (the Requirement Types, are not used), thus the occurrences for requirements can be specified in the node template
definition. Moreover, if we look at the Interface definition in the types and templates, the TOSCA specifies that the section 3.8.3.2. that interface_definitions can augment, those provided by the ones declared when defining the node
type, i.e. we can add or change Interfaces or operations. Thus I propose to allow capability_definition augmentation in the node template,
where besides assigning properties and attributes we can change the occurences of a capability.
â This is also part of a larger discussion of type and type changing. Do we consider the capability where we changed the occurences value of being of the same type, or being of an âanonymousâ type that extends from the original
type? The same is valid when overriding the predefined node types as exemplified in section 2.3. BR, /calin From:
Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com> Hi Shitao, where would you set the occurrences [1,2] ? Arturo From: Lishitao <lishitao@huawei.com>
Hi Arturo What is your issue here? From my understanding, if the expected number of VduCp connected to a Vdu.Compute is 2 for example, the occurrences should set to [1:2].
Regards shitao åää:
Arturo Martin De Nicolas [mailto:arturo.martin-de-nicolas@ericsson.com]
Hi Chris, As I read the grammar, a node template includes capability assignments. A capability assignment does not support the âocurrencesâ keyname. A node type definition includes capability definitions. A capability definition supports the âocurrencesâ keyname. SOL001 Vdu.Compute node type definition is generic. It has
ocurrences: [1, UNBOUNDED] in the virtual_binding capability but then each node implementation may support a certain number of VduCps, i.e. I would like to be able in a node template to indicate how many virtual_bindings I can support. Best regards, Arturo From: Chris Lauwers <lauwers@ubicity.com>
ocurrences: [ 0, 2] Chris From: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>
Hi Chris, Ok, so how do I express in my node template definition that my virtual_binding capability can be target of 2 requirements (not more)? Regards, Arturo From: Chris Lauwers <lauwers@ubicity.com>
Hi Arturo, The âoccurrencesâ keyname here doesnât mean that there can be multiple instances of the capability. Instead, it means that the capability can be the (shared) target for multiple requirements, meaning it can terminate multiple
relationships. Even when a capability terminates multiple relationships, there is still only one single capability. Chris From: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>
Hi, Yesterday we clarified in the TOSCA YAML call that many of the assignments lists in the node template definition should be encoded as maps, for example, the capability_assignments. So how do we do when we have a node template definition with a capability with occurrences > 1 ? For example, in SOL001 the Vdu.Compute node type definition has the capability virtual_binding with occurrences: [ 1, UNBOUNDED ].
I want to define a node template of this type with two occurrences of the virtual_binding capability, because it has two VduCps. If capability assignments is a map, I cannot say: capabilities: virtual_binding virtual_binding Thoughts? Thanks. Arturo |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]