Hi Thinh,
The purpose of policies is to control mechanism. Before we can start talking about policies that can control the process of creating multiple node instances from the same template,
we need to first discuss what the mechanism is that enables this functionality in the first place.
Chris
From: Nguyenphu, Thinh (Nokia - US/Irving) [mailto:
thinh.nguyenphu@nokia.com]
Sent: Tuesday, March 27, 2018 8:54 AM
To: Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com>; Chris Lauwers <
lauwers@ubicity.com>; Lishitao <
lishitao@huawei.com>;
claude.noshpitz@att.com; Matthew Rutkowski (
mrutkows@us.ibm.com) <
mrutkows@us.ibm.com>; Priya T G <
priya.g@netcracker.com>;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com>
Subject: RE: InstantiationLevel discussion paper
Hi,
Another alternative solution for v1.1 and v1.2 is to model instantiationLevel based policy type. I have a draft proposal which was share with some of you. Now, I am modify it to address your concern.
Perhaps we can discuss it too on today call. Thinh
From: Arturo Martin De Nicolas [ mailto:
arturo.martin-de-nicolas@ericsson.com ]
Sent: Tuesday, March 27, 2018 4:34 AM
To: Chris Lauwers <
lauwers@ubicity.com >; Lishitao <
lishitao@huawei.com >;
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
mrutkows@us.ibm.com >; Priya T G <
priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) <
thinh.nguyenphu@nokia.com >;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com >
Subject: RE: InstantiationLevel discussion paper
Hello Chris, all,
Calin and me have explored this further. As the properties of the substituted node are available as inputs to the substituting node, we think this may work using the get_input function
in the substituting node template (not the get_property as I previously suggested).
Please, see attached schema with the modified proposal.
Best regards,
Arturo
From: Chris Lauwers [ mailto:
lauwers@ubicity.com ]
Sent: Monday, March 26, 2018 6:05 PM
To: Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >; Lishitao <
lishitao@huawei.com >;
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
mrutkows@us.ibm.com >; Priya T G <
priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) (
thinh.nguyenphu@nokia.com ) <
thinh.nguyenphu@nokia.com >;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com >
Subject: RE: InstantiationLevel discussion paper
Hi Arturo,
Are you suggesting that the substituting node template would use get_property to reach into the template that has the substituted node? If so, I don’t believe that should be allowed, since there
is no way to ensure (at design time) that this would result in a valid operation.
Chris
From: Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >
Sent: Monday, March 26, 2018 7:20 AM
To: Lishitao <
lishitao@huawei.com >; Chris Lauwers <
lauwers@ubicity.com >;
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
mrutkows@us.ibm.com >; Priya T G <
priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) (
thinh.nguyenphu@nokia.com ) <
thinh.nguyenphu@nokia.com >;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com >
Subject: RE: InstantiationLevel discussion paper
Hello Chris, Shitao,
Thanks for the feedback. I agree, the solution for instantiation level that will hopefully be developed in 1.3 should give answer to all these important issues that Chris raises.
My proposal, if we make it working, is a workaround until that solution is in place.
Chris, I have one question below
in green .
Best regards,
Arturo
From: Lishitao [ mailto:
lishitao@huawei.com ]
Sent: Monday, March 26, 2018 4:22 AM
To: Chris Lauwers <
lauwers@ubicity.com >; Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >;
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
mrutkows@us.ibm.com >; Priya T G <
priya.g@netcracker.com >;
Nguyenphu, Thinh (Nokia - US/Irving) (
thinh.nguyenphu@nokia.com ) <
thinh.nguyenphu@nokia.com >;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com >
Subject: ?? : InstantiationLevel discussion paper
Hi Chris and Arturo
I think Chris has pointed out some interesting and important issues for the multiple instances design. I agree we need to take this as one of the high priority feature to be support in v1.3.
Regards
shitao
??? : Chris Lauwers [ mailto:
lauwers@ubicity.com ]
???? : 2018 ? 3 ? 24 ? 2:12
??? : Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >;
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
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 >;
tosca@lists.oasis-open.org ?? : Calin Curescu <
calin.curescu@ericsson.com >
?? : RE: InstantiationLevel discussion paper
Hi Arturo,
Thanks for putting this together. We’ll use it as the basis for further discussion.
Comments in-line:
From: Arturo Martin De Nicolas [ mailto:
arturo.martin-de-nicolas@ericsson.com ]
Sent: Monday, March 19, 2018 10:01 AM
To:
claude.noshpitz@att.com ; Matthew Rutkowski (
mrutkows@us.ibm.com ) <
mrutkows@us.ibm.com >; Chris Lauwers <
lauwers@ubicity.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 >;
tosca@lists.oasis-open.org Cc: Calin Curescu <
calin.curescu@ericsson.com >
Subject: InstantiationLevel discussion paper
Hello all,
As already discussed, there is no clear equivalent to the NFV instantiation level in the TOSCA Simple Profile in YAML (i.e. a property that indicates how many instances of each node template should be instantiated
at deployment of the service template). I think this is a candidate feature for 1.3.
Yes, there is currently no language support for allowing the same node template to be instantiated multiple times. Your proposal circumvents this by making it the responsibility of the “create” operation to create
multiple instances (based on the instantiation level data structure). While this will work, it means that the orchestrator (and any ongoing operational management systems) has no knowledge of the individual instances.
I fully support your suggestion that we should address this in Version 1.3. You have previously proposed to support the ‘occurrences’ keyname in node templates. This is likely the correct starting point, but
we need to think through the implications on the rest of the topology template. Specifically:
·
If node template A supports multiple occurrences, and node template B supports multiple occurrences, and we have a relationship between A and B, what is the desired cardinality of the relationship between
A and B? Full mesh from all instances of A to all instances of B? Single relationship between one instance of A and one instance of B? What if A and B don’t have the same number of occurrences? We need to document the various use cases and then decide which
grammar is required to create those use cases.
·
If node template A supports multiple occurrences, and some of A’s properties are initialized using get_input statements, how do we specify that a list of values must be provided for each named input?
How do we specify which value in that list goes to which instance of A?
·
If node template A supports multiple occurrences, and node template B uses a { get_property, [A, <property_of_A> ] }, then which specific instance of A will be used in the corresponding property value
of B?
·
If node template A supports multiple occurrences, and node template A is “realized” through substitution mapping, do we need any extensions to the substitution _mapping grammar to accommodate this?
I’m sure there are other potential issues, but we can start with these.
I have uploaded a discussion paper related to this issue. The intention of the paper is not to propose a solution for 1.3, but something that ETSI NFV could use in the meantime, using the mechanisms available in
YAML 1.1 or 1.2.
One of the concerns you point out is that, independent of multiple occurrences, the get_property syntax can get cumbersome when complex data types are used. I’m not sure that this is necessarily a problem, but
I agree that we need to do a better job of clarifying what the appropriate syntax is for various scenarios that involve list, map, or complex data. Specifically:
·
For properties of type list, how do we specify the index of a specific entry in the list?
·
For properties of type map, how do we specify the entry that corresponds to a specific key value
·
For multiple instances of a requirement, how do we specify the index of a specific requirement instance in the list
·
It is currently not possible to use get_property to retrieve property values of relationships
As the instantiationLevel is a complex type and there is a need to pass information from one node template to another, the grammar becomes unclear. I am looking for advice if this may be a base for a solution.
The mechanism for passing information from one node template to another is through the ‘substitution_mapping’ grammar. I agree, that this grammar can get confusing, since in the v1.2 spec we’re overloading this
grammar for two completely different purposes:
Arturo: if Node_A is an abstract node template and Node_b is a node included in a topology template which substitutes for Node_A, is it also possible to pass information from Node_A to Node_b with the get_property
function (used e.g. in the interfaces definition of Node_b)?
1.
Mapping : specify how properties, attributes, capabilities, requirements, and interfaces from one node template are mapped to corresponding entities in a substituting
service template.
2.
Matching : when the orchestrator finds multiple service templates that can be used to substitute a node template, how does the orchestrator select the best match?
The examples in Chapter 14 do not properly highlight these two purposes. I strongly believe we need to more clearly separate them. In my opinion, substitution mapping grammar should be used exclusively to specify
the intended mappings. Different grammar should then be used to drive matching. Since we use node filters in other parts of the spec for similar purposes, I suggest we investigate the use of node filters to guide matching decisions when multiple possible substituting
template are found.
Claude and Matt, is it possible to add this discussion to the agenda for tomorrow’s meeting?
TOSCA_InstantiationLevel_Discussion.docx
Best regards,
Arturo
Chris