[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Edge cases in maps: missing content (empty content)
Hi Gabor, A couple more comments:
1.
On second thought, perhaps your Case 5 should be valid after all. How strongly do you feel about that use case?
2.
For the ETSI NFV use case, I’m not convinced that “presence of an operation definition” in a node template should give any indication of whether the operation is supported. Here is my reasoning:
·
If I understand the IFA and SOL documents correctly, then the requirement is for an API call to the orchestrator to query the set of supported lifecycle management operations for a given VNF.
·
However, external API calls to the orchestrator never call operations on a VNF directly,
they call workflows on the service topology that contains the VNF. These workflows in turn call lifecycle management operations on nodes (including the VNF node).
·
This means that a (IFA 007) lifecycle management operation is only supported if there is a corresponding workflow defined in the template that contains the VNF.
·
This further means that any API call to query the supported lifecycle management operations should look at the set of workflows in a template, not at the set of operations on the VNF node template. Thanks, Chris From: Marton, Gabor (Nokia - HU/Budapest) [mailto:gabor.marton@nokia.com]
Hi Chris, thanks a lot for your reply (and no problem at all about not replying earlier)! Regarding your position on “presence of an operation definition” in a node template, I believe we need to discuss it in ETSI NFV SOL001, and might conclude that we need to fix the specs. Greetings, Gábor From: Chris Lauwers <lauwers@ubicity.com>
Hi Gabor, Apologies for the late reply. I’m not sure there is an “official” OASIS TOSCA position on which of these are valid, but here is my opinion:
-
Yes, I believe Case 1 and Case 2 are both valid and identical.
-
I believe that your Case 3 and Case 4 are both valid and identical as well.
-
I don’t believe your Case 5 is valid. It effectively says that the default value for property_1 (of type string) is None (or Null). I don’t believe that None (or Null) are valid values for type string.
That said, I don’t believe that “presence of an operation definition” in a node template should have any meaning associated with it. In particular, I don’t believe that presence of an operation should specify whether that operation is supported
or not. Defining an interface on a node type implies that all operations of that interface are supported by all nodes of that node type. Of course, some operations may not have implementations defined, in which case the operation becomes a noop. Thanks, Chris From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Marton, Gabor (Nokia - HU/Budapest) Dear TOSCA Experts, as these and similar edge cases are not explicitly controlled by the TOSCA YAML specifications, I am asking for your opinion. Which one(s) of the following cases are valid syntactically? tosca_definitions_version: tosca_simple_yaml_1_2 interface_types: interface_type_1: derived_from: tosca.interfaces.Root operation_1: description: .. node_types: node_type_1: derived_from: tosca.nodes.Root properties: property_1: type: string required: false node_type_2: derived_from: tosca.nodes.Root interfaces: interface_1: type: interface_type_1 topology_template: node_templates: node_template_1_1: type: node_type_1 properties:
# case 1 node_template_1_2: type: node_type_1 properties: {}
# case 2 node_template_2_1: type: node_type_2 interfaces: interface_1: operation_1:
# case 3 node_template_2_2: type: node_type_2 interfaces: interface_1: operation_1: {}
# case 4 data_types: data_type_1: derived_from: tosca.datatypes.Root properties: property_1: type: string default:
# case 5 Cases #1 and #2 are assumed to have the same meaning. Similarly cases #3 and #4. Motivation for cases #3 and #4: indicate availability of lifecycle management operations in VNF descriptors (without specifying further details). In the ETSI NFV SOL001 specification, we have an example like this, basically case #3 (the
scale operation inserted by me here for better clarity): tosca_definitions_version: tosca_simple_yaml_1_2 .. node_types: MyCompany.SunshineDB.1_0.1_0: derived_from: tosca.nodes.nfv.VNF .. topology_template: .. node_templates: SunshineDB: type: MyCompany.SunshineDB.1_0.1_0 .. interfaces: Vnflcm: instantiate: scale: .. Related text in SOL001:
Motivation for the other cases: understand the standpoint, to achieve better compatibility of parsers (better interoperability of products). Best regards, Gábor |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]