[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, could you clarify which part isn’t in line with SOL 001? Thanks, Chris From: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Hi Chris, yes, that’s correct (except that it is not in line with the current SOL001 specification). Greetings, Gábor From: Chris Lauwers <lauwers@ubicity.com>
Hi Gabor, Based on your response, it appears that we agree on the following: “The NFVO can figure out which lifecycle management operations are supported by a VNF by looking at the workflows defined in the topology template”. This functionality is fully supported in Version 1.2 using TOSCA workflows (you’re correct that if you want to use non-TOSCA workflows, then 1.3 support is required).
Thanks, Chris From: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Hi Chris, 1. Regarding Case 5 (“default” key with missing value), I don’t fell strongly about it, in fact I would be more happy if it was declared as invalid. (The motivation for asking about it was indeed to see the boundaries.) 2. No, actually the required mechanisms in ETSI are different from your interpretation:
No, the set of supported LCM operations are not communicated via an API call; instead, this information needs to be in the VNFD (the NFVO---the orchestrator that uses the VNFM to managed the VNF resources---reads a lot of important information
about the VNF from the VNFD à the VNFD is for two different audiences, the VNFM and the NFVO, yet it is one document).
Apart from TOSCA: the NFVO (orchestrator) calls LCM operations on the API of the VNFM (VNF manager) which in turn calls resource manipulation operations on the VIM (virtual infrastructure manager i.e. the cloud). Taking TOSCA into account:
So it is a “double-layer” TOSCA orchestrator altogether, the upper layer (NFVO) delegating certain tasks to the lower layer (VNFM).
Yes, that’s correct. But as template-level workflows cannot have custom implementation artifacts associated (in TOSCA v1.2), these workflows are associated as implementation to the operations on the VNF node type at the moment (current
SOL001). In a future version of SOL001, which will rely on TOSCA v1.3, these workflows will be represented as template-level workflows --- at least to my best knowledge, this is the strategic direction in SOL001 (someone from
@SOL001, please correct me if I am wrong).
Replacing “any API call to query the supported lifecycle management operations” with “the NFVO, when reading the VNFD”, I agree with the conclusion, assuming the TOSCA v1.3-based anticipated future SOL001
specification. Greetings, Gábor From: Chris Lauwers <lauwers@ubicity.com>
Hi Gabor, A couple more comments:
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:
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]