OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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>
Sent: Thursday, January 31, 2019 12:01 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: Edge cases in maps: missing content (empty content)

 

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>
Sent: Thursday, January 31, 2019 12:47 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
Subject: RE: Edge cases in maps: missing content (empty content)

 

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>
Sent: Wednesday, January 30, 2019 8:51 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: Edge cases in maps: missing content (empty content)

 

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:

 

    • 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.

 

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).

 

    • 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).

 

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:

 

  • on the level of the NS (network service), the NFVO calls “workflows on the service topology that contains the VNF” as you pointed out; these workflows in turn delegate the task to the VNFM via the standard VNF LCM operations (Create VNF identifier, Instantiate VNF, Terminate VNF, Delete VNF identifier, Scale VNF, etc); the NS is described by the NSD, the available VNF LCM operations are described by the VNFD per participating VNF;
  • on the level of the VNF, the VNFM executes the standard VNF LCM operations (requested by the NFVO) in form of workflows; these workflows in turn contact the VIM; these workflows are described by the so called “LCM scripts” in the VNFD which manifest as implementation of operations declared in the VNF node type.

 

So it is a “double-layer” TOSCA orchestrator altogether, the upper layer (NFVO) delegating certain tasks to the lower layer (VNFM).

 

    • 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.

 

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).

 

    • 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.

 

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>
Sent: Friday, January 25, 2019 10:44 PM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
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]
Sent: Wednesday, January 23, 2019 9:43 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: Edge cases in maps: missing content (empty content)

 

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>
Sent: Tuesday, January 22, 2019 9:56 PM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
Subject: RE: Edge cases in maps: missing content (empty content)

 

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)
Sent: Friday, January 11, 2019 3:50 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Edge cases in maps: missing content (empty content)

 

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:

 

  • “In the above example, as there is no implementation and inputs specified to the operations, the built-in implementation of the operation is invoked when the Instantiate VNF request is received on the LCM interface of the Or-Vnfm reference point” (section 6.7.1.5).
  • “All VNF supported LCM operations shall be listed in the service template, except ‘instantiate‘ and ‘terminate‘ that may be omitted, as specified in ETSI GS NFV-IFA011 [1] for the supportedOperation attribute of a deployment flavour” (section 6.7.1.3).

 

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]