[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: InstantiationLevel discussion paper
Completely agree:
Thanks, Chris From: Lishitao <lishitao@huawei.com> Hi Chris We have the same concern as you have. Maybe we need to deprecate the Scalable capability in V1.3. Regards shitao 发件人:
Chris Lauwers [mailto:lauwers@ubicity.com]
I must admit I don’t understand tosca.capabilities.Scalable. Based on the current TOSCA standard, capabilities only exist for the purpose of being able to be the target of a relationship
(that’s what makes a capability different from just a regular property). What is the relationship that has tosca.capabilities.Scalable as its target, and types of operations would have to be invoked on this relationship in order to make the target node scale? Chris
From: Lishitao [mailto:lishitao@huawei.com]
Hi Chris What do you think of the usage of tosca.capabilities.Scalable? It indicates min_instances, max_instances and default_instances which will be applied to the node that
contains this capability. Based on what you pointed out, this capability shall not be supported by TOSCA orchestrator at this moment, right? And we also questioned that why scalable is a capability in TOSCA. I think we also need to clarify this ASAP.
Regards shitao 发件人:
Chris Lauwers [mailto:lauwers@ubicity.com]
Hi, I’m attaching a write-up I did on this topic. It includes suggested extensions to the grammar that could be used to control the number of instances. It also points out some areas where more exploration
is necessary. Chris From: Lishitao <lishitao@huawei.com>
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]
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]
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:
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:
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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]