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

Comments inline
 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Tuesday, September 04, 2018 7:32 AM
To: Chris Lauwers; Arturo Martin De Nicolas; Lishitao; claude.noshpitz@att.com; Matt Rutkowski; Priya T G; Nguyenphu, Thinh (Nokia - US/Irving) (thinh.nguyenphu@nokia.com); KATZMAN, ANATOLY; Steve Baillargeon
Subject: Re: Capability assignments in node template


 
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 4 th occurrence of local_storage,


o    
if the previous dangling requirement resolves to zero relationships then my_storage_B will be mapped to the 2 nd 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>
Date: Monday, 3 September 2018 at 05:20
To: Arturo Martin De Nicolas <arturo.martin -de-nicolas@ericsson.com>, Calin Curescu <calin.curescu@ericsson.com>, Lishitao <lishitao@huawei.com>, "claude.noshpitz@att.com" <claude.noshpitz@att.com>,
Matt Rutkowski <mrutkows@us.ibm.com>, Priya T G <priya.g@netcracker.com>, "Nguyenphu, Thinh (Nokia - US/Irving) (thinh.nguyenphu@nokia.com)" <thinh.nguyenphu@nokia.com>, "KATZMAN, ANATOLY" <ak435s@intl.att.com>, Steve Baillargeon <steve.baillargeon@ericsson.com>,
Chris Lauwers <lauwers@ubicity.com>
Subject: RE: Capability assignments in node template


 

With respect to requirement assignments:
 
There are really two completely different use cases for requirement assignments:
 

The first use case is the straightforward one, where the requirement assignment specifies the specific capability (and the node template that contains that capability) that fulfills the requirement.
The requirement assignment typically also specifies the relationship template (either in-line or by reference) that is used to create the relationship (where that relationship template can contain properties). The second use case is the dangling requirement use case. In this scenario, the requirement assignment doesn t specify how the requirement is fulfilled, but rather it further narrows (using
node filters) the set of capabilities (and containing nodes) that can be used to fulfill the requirement. Presumably, the orchestrator will use the node filter to construct a query to retrieve candidate capabilities (and nodes) from its inventory. This is
the scenario where the requirement assignment can change the node type, capability type, and relationship type that were specified in the requirement definition (in the node type), AS LONG AS THOSE TYPES ARE DERIVED FROM THE CORRESPONDING TYPES SPECIFIED
IN THE REQUIREMENT DEFINITION. This refinement scenario is similar to the refinement scenario for data types that we have been discussing over the last two weeks.
 
Please let me know if any of this is not clear.
 
Thanks,
 
Chris
 


From: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>

Sent: Monday, August 13, 2018 8:34 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Chris Lauwers <lauwers@ubicity.com>; Lishitao <lishitao@huawei.com>; claude.noshpitz@att.com; Matt Rutkowski <mrutkows@us.ibm.com>; Priya T G <priya.g@netcracker.com>; Nguyenphu, Thinh (Nokia - US/Irving)
(thinh.nguyenphu@nokia.com) <thinh.nguyenphu@nokia.com>; KATZMAN, ANATOLY <ak435s@intl.att.com>; Steve Baillargeon <steve.baillargeon@ericsson.com>
Subject: RE: Capability assignments in node template


 
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

Sent: Friday, August 10, 2018 1:26 PM
To: Chris Lauwers < lauwers@ubicity.com >; Lishitao < lishitao@huawei.com >; Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Priya T G < priya.g@netcracker.com >; Nguyenphu, Thinh (Nokia - US/Irving)
( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >; Steve Baillargeon < steve.baillargeon@ericsson.com >
Subject: Re: Capability assignments in node template


 
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 >
Date: Friday, 10 August 2018 at 05:35
To: Lishitao < lishitao@huawei.com >, Calin Curescu < calin.curescu@ericsson.com >, Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >,
" claude.noshpitz@att.com " < claude.noshpitz@att.com >, Matt Rutkowski < mrutkows@us.ibm.com >, Priya T G < priya.g@netcracker.com >,
"Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com )" < thinh.nguyenphu@nokia.com >, "KATZMAN, ANATOLY" < ak435s@intl.att.com >,
Steve Baillargeon < steve.baillargeon@ericsson.com >
Cc: Chris Lauwers < lauwers@ubicity.com >
Subject: RE: Capability assignments in node template


 

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

Sent: Thursday, August 09, 2018 8:22 PM
To: Lishitao < lishitao@huawei.com >; Calin Curescu < calin.curescu@ericsson.com >; Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Priya T G < priya.g@netcracker.com >; Nguyenphu, Thinh (Nokia - US/Irving)
( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >; Steve Baillargeon < steve.baillargeon@ericsson.com >
Cc: Chris Lauwers < lauwers@ubicity.com >
Subject: RE: Capability assignments in node template


 
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 >

Sent: Thursday, August 09, 2018 8:14 PM
To: Calin Curescu < calin.curescu@ericsson.com >; Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >; Chris Lauwers < lauwers@ubicity.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Priya T G < priya.g@netcracker.com >; Nguyenphu, Thinh (Nokia - US/Irving)
( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >; Steve Baillargeon < steve.baillargeon@ericsson.com >
Subject: çå : Capability assignments in node template


 
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 ]

å é æé :
2018 å 8 æ 9 æ
23:26
æää : Arturo
Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >; Lishitao < lishitao@huawei.com >; Chris Lauwers < lauwers@ubicity.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Priya T G < priya.g@netcracker.com >; Nguyenphu, Thinh (Nokia - US/Irving)
( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >; Steve Baillargeon < steve.baillargeon@ericsson.com >
ä é :
Re: Capability assignments in node template


 
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 >
Date: Thursday, 9 August 2018 at 09:32
To: Lishitao < lishitao@huawei.com >, Chris Lauwers < lauwers@ubicity.com >, Calin Curescu < calin.curescu@ericsson.com >, " claude.noshpitz@att.com "
< claude.noshpitz@att.com >, Matt Rutkowski < mrutkows@us.ibm.com >, Priya T G < priya.g@netcracker.com >, "Nguyenphu, Thinh (Nokia
- US/Irving) ( thinh.nguyenphu@nokia.com )" < thinh.nguyenphu@nokia.com >, "KATZMAN, ANATOLY" < ak435s@intl.att.com >, Steve Baillargeon
< steve.baillargeon@ericsson.com >
Subject: RE: Capability assignments in node template


 

Hi Shitao,
 
where would you set the occurrences [1,2] ?
 
Arturo
 
 


From: Lishitao < lishitao@huawei.com >

Sent: Thursday, August 09, 2018 9:31 AM
To: Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >; Chris Lauwers < lauwers@ubicity.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Priya T G < priya.g@netcracker.com >; Nguyenphu, Thinh (Nokia - US/Irving)
( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >; Steve Baillargeon < steve.baillargeon@ericsson.com >
Subject: çå : Capability assignments in node template


 
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 ]

å é æé :
2018 å 8 æ 9 æ
15:03
æää : Chris
Lauwers < lauwers@ubicity.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Lishitao < lishitao@huawei.com >; Priya T G < priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >;
Steve Baillargeon < steve.baillargeon@ericsson.com >
ä é :
RE: Capability assignments in node template


 
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 >

Sent: Wednesday, August 08, 2018 6:35 PM
To: Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Lishitao < lishitao@huawei.com >; Priya T G < priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >;
Steve Baillargeon < steve.baillargeon@ericsson.com >
Cc: Chris Lauwers < lauwers@ubicity.com >
Subject: RE: Capability assignments in node template


 
ocurrences: [ 0, 2]
 
Chris
 


From: Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >

Sent: Wednesday, August 08, 2018 9:16 AM
To: Chris Lauwers < lauwers@ubicity.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Lishitao < lishitao@huawei.com >; Priya T G < priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >;
Steve Baillargeon < steve.baillargeon@ericsson.com >
Subject: RE: Capability assignments in node template


 
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 >

Sent: Wednesday, August 08, 2018 6:04 PM
To: Arturo Martin De Nicolas < arturo.martin-de-nicolas@ericsson.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Lishitao < lishitao@huawei.com >; Priya T G < priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >;
Steve Baillargeon < steve.baillargeon@ericsson.com >
Cc: Chris Lauwers < lauwers@ubicity.com >
Subject: RE: Capability assignments in node template


 
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 >

Sent: Wednesday, August 08, 2018 2:40 AM
To: Chris Lauwers < lauwers@ubicity.com >; Calin Curescu < calin.curescu@ericsson.com >;
claude.noshpitz@att.com ; Matt Rutkowski < mrutkows@us.ibm.com >; Lishitao < lishitao@huawei.com >; Priya T G < priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) ( thinh.nguyenphu@nokia.com ) < thinh.nguyenphu@nokia.com >; KATZMAN, ANATOLY < ak435s@intl.att.com >;
Steve Baillargeon < steve.baillargeon@ericsson.com >
Subject: Capability assignments in node template


 
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