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: Question on mandatory properties vs. node type substitution


Thanks Gabor, I believe I understand the issue now. In fact, this is part of a broader discussion we’ve been having about mapping of attributes, which are “outgoing” properties using your terminology. We’ve had good discussions about how to generally handle these scenarios but no agreement yet. We’ll try to document our current thinking over the next 2 weeks and we hope to get this finalized before v1.3 is finished.

 

Thanks,

 

Chris

 

 

From: Marton, Gabor (Nokia - HU/Budapest) [mailto:gabor.marton@nokia.com]
Sent: Friday, January 04, 2019 1:58 AM
To: Chris Lauwers; tosca@lists.oasis-open.org
Subject: RE: Question on mandatory properties vs. node type substitution

 

Happy New Year, Chris and All TOSCA Experts,

 

yes, your points are basically in line with the ETSI NFV SOL001 specifications, except for the problem with the flavour_description property of the VNF node.

 

Going step by step---sorry about the long mail, but unfortunately I cannot make it shorter (I did condense the question in my original mail, but as a result of compression, it had nothing to do with ETSI NFV SOL001 anymore hence the motivation had been lost):

 

  • Consider an abstract VNF node template that needs to be substituted

 

The relevant (for the current discussion) part of the VNF node type is, most relevant parts highlighted:

 

node_types:

  tosca.nodes.nfv.VNF:

    derived_from: tosca.nodes.Root

    ..

    properties:

      descriptor_id:

        type: string

        description: Globally unique identifier of the VNFD

        required: true

      ..

      flavour_id:

        type: string

        description: Identifier of the Deployment Flavour within the VNFD

        required: true

      flavour_description:

        type: string

        description: Human readable description of the DF

        required: true

    requirements:

      - virtual_link:

          capability: tosca.capabilities.nfv.VirtualLinkable

          ..

    ..

 

From this generic VNF node type, VNF vendors derive their own types in the VNFD (VNF descriptor), e.g.:

 

node_types:

  MyCompany.SunshineDB.1_0.1_0:

    derived_from: tosca.nodes.nfv.VNF

    properties:

      descriptor_id:

        type: string

       constraints: [ valid_values: [ b1bb0ce7-ebca-4fa7-95ed-4840d70a1177 ] ]

        default: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177

      ..

      flavour_id:

        type: string

        constraints: [ valid_values: [ simple, complex ] ]

        default: simple

      ..

 

 

  • Presumably, a specific flavor_id will be provided as a property value of the abstract VNF node.

 

Yes, and in fact it takes place in two places:

 

Substitution place #1: in case of a multi-DF VNFD (DF = Deployment Flavour), the so-called top-level template contains an abstract VNF-derived node template:

 

imports:

  - ..

  - sunshineVNF.yaml # contains the above definition of MyCompany.SunshineDB.1_0.1_0

  - ..

 

topology_template:

  inputs:

    selected_flavour:

      type: string

      description: VNF deployment flavour selected by the consumer. It is provided in the API

 

  node_templates:

    vnf:

        type: MyCompany.SunshineDB.1_0.1_0

        properties:

          flavour_id: { get_input: selected_flavour }

          descriptor_id: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177

          provider: MyCompany

          product_name: SunshineDB

          software_version: '1.0'

          descriptor_version: '1.0'

          vnfm_info:

            - MyCompany

        requirements:

          #- virtual_link_backend # mapped in lower-level templates

          #- virtual_link_service # mapped in lower-level templates

        # get_input function would be used by a TOSCA orchestrator at run time to access the selected flavour id. If the deployment is not done by a TOSCA orchestrator above function may not be needed

 

Substitution place #2: in the NSD (NS = Network Service), the VNF vendor-specific VNF node types are used in combination with the flavour_id property value constraints, e.g.:

 

topology_template:

  node_templates:

    vnf_1:

      type: MyCompany.SunshineDB.1_0.1_0

      properties:

        flavour_id: simple

        ..

      requirements:

        - virtual_link: vl_1

 

    vnf_2:

      type: YourCompany.Example.1_0.1_0

      ..

 

    vl_1:

      type: tosca.nodes.nfv.NsVirtualLink

      ..

 

 

  • Based on the value of the flavor_id, the orchestrator will select the appropriate substituting template

 

Yes, the substituting template (representing the Deployment Flavour in ETSI terminology) matches the desired flavour_id value:

 

topology_template:

  substitution_mappings:

   node_type: MyCompany.SunshineDB.1_0.1_0

    properties:

      flavour_id: simple

      ..

    requirements:

      virtual_link: [ ecp, virtual_link ]

 

  node_templates:

    ..

 

    ecp:

      type: tosca.nodes.nfv.VduCp

      ..

  ..

 

  • The substituting template presumably will use TOSCA requirements to express its resource requirements. These resource requirements must not be communicated back to the substituted node as property values. Instead, they need to remain as requirements that need to be fulfilled by the orchestrator.

 

No problem with the resource requirements, see e.g. the mapping of the virtual_link requirement above.

 

 

The problem is with the flavour_description property which is an “outgoing” property---now the same substituting template fragment also containing this property:

 

topology_template:

  substitution_mappings:

   node_type: MyCompany.SunshineDB.1_0.1_0

    properties:

      flavour_id: simple

      flavour_description: non-scalable variant

      ..

    requirements:

      virtual_link: [ ecp, virtual_link ]

 

  node_templates:

    ..

 

    ecp:

      type: tosca.nodes.nfv.VduCp

      ..

  ..

 

If an orchestrator wants to display the content of the flavour_description on a GUI, it needs to find a TOSCA-compliant path to the value of this property. As the top-level VNFD is the entry point to the hierarchy of service templates, it is logical to expect that the orchestrator---the TOSCA parser in it---is able to extract this value as the value of the flavour_description property of the abstract VNF node template (called vnf in the example above). So this property needs to be set bottom-up.

 

Greetings,

 

Gábor

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Sent: Monday, December 17, 2018 12:51 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
Subject: RE: Question on mandatory properties vs. node type substitution

 

Hi Gabor,

 

Thanks for the explanation, since this may not be a proper use of substitution mappings. Specifically, substitution mapping does not provide an ability for the substituting template to set property values in the substituted node.

 

If I understand your use case, then the correct way to communicate resource requirements back to the NFVO is by using, well, requirements:

 

  • Consider an abstract VNF node template that needs to be substituted
  • Presumably, a specific flavor_id will be provided as a property value of the abstract VNF node.
  • Based on the value of the flavor_id, the orchestrator will select the appropriate substituting template
  • The substituting template presumably will use TOSCA requirements to express its resource requirements. These resource requirements must not be communicated back to the substituted node as property values. Instead, they need to remain as requirements that need to be fulfilled by the orchestrator.

 

Is this inconsistent with the ETSI spec?

 

Thanks,

 

Chris

 

From: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Sent: Saturday, December 15, 2018 12:46 PM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: Question on mandatory properties vs. node type substitution

 

Hi Chris,

 

thanks a lot for your response.

 

The scenario is about setting a property value in an abstract node by a substituting template, i.e. bottom-up. This unusual need, like a number of others discussed with you and other TOSCA experts in relation to ETSI NFV SOL001 (VNF descritor, NS descriptor), comes from the unusual use of TOSCA: a VNFD is at the same time (1) a descriptor with “read-only”/output values for informing the NFVO about the resource requirements of a VNF so that the NFVO can do necessary resource allocations and granting, and (2) a declarative descriptor with input values to the VNFM for defining the workload to be managed. We ended up with a VNF node type of which one property (flavour_id) is top-down (2) whereas others (flavour_description, descriptor_id, …) are bottom-up (1).

 

Wishing you a Merry Christmas and a Happy New Year,

 

Gábor

 

p.s.: back in the office from 3 January.

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Sent: Tuesday, December 11, 2018 6:42 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
Subject: RE: Question on mandatory properties vs. node type substitution

 

Hi Gabor,

 

Apologies for the late reply.

 

I’m not sure if I understand your scenario correctly, but in general, property values in an abstract node will never be set by a substituting template. The must be set in the top-level template that includes the abstract node (e.g. using get_input functions) and then these values will be propagated to inputs of the substituting template (assuming the property mappings are set up correctly).

 

Of course, since each property is automatically reflected in a corresponding attribute with the same name, the attribute values will get retrieved from the substituting template (assuming outputs of the substituting template are properly mapped onto attributes of the abstract node).

 

Please let me know if I misunderstood your question.

 

Thanks,

 

Chris

 

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Marton, Gabor (Nokia - HU/Budapest)
Sent: Tuesday, November 06, 2018 12:52 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Question on mandatory properties vs. node type substitution

 

Dear TOSCA Experts,

 

the following question is related to a problem under discussion in the ETSI NFV SOL001 group.

 

In the below second service template (example-top.tosca.yaml), can the value of property_2 come from a substitution template? In other words, is the second service template valid?

 

example-type.tosca.yaml:

 

tosca_definitions_version: tosca_simple_yaml_1_2

 

node_types:

  node_type_1:

    derived_from: tosca.nodes.Root

    properties:

      property_1:

        type: string

        constraints:

          - valid_values: [ value_1, value_2 ]

      property_2:

        type: string

 

example-top.tosca.yaml:

 

tosca_definitions_version: tosca_simple_yaml_1_2

 

imports:

  - example-type.tosca.yaml

 

topology_template:

  node_templates:

    node_template_1:

      type: node_type_1

      properties:

        property_1: value_1 # property value constraint for matching

 

  outputs:

    output_1:

      value: { get_property: [ node_template_1, property_2 ] } # value_3 from the sole matching substitution

 

example-subst-1.tosca.yaml:

 

tosca_definitions_version: tosca_simple_yaml_1_2

 

imports:

  - example-type.tosca.yaml

 

topology_template:

  substitution_mappings:

    node_type: node_type_1

    properties:

      property_1: value_1

      property_2: value_3

 

example-subst-2.tosca.yaml:

 

tosca_definitions_version: tosca_simple_yaml_1_2

 

imports:

  - example-type.tosca.yaml

 

topology_template:

  substitution_mappings:

    node_type: node_type_1

    properties:

      property_1: value_2

      property_2: value_4

 

In case the second service template is invalid, we need to use a work-around which is not perfect, e.g.:

 

example-type.tosca.yaml (modified):

 

tosca_definitions_version: tosca_simple_yaml_1_2

 

node_types:

  node_type_1:

    derived_from: tosca.nodes.Root

    properties:

      property_1:

        type: string

        constraints:

          - valid_values: [ value_1, value_2 ]

      property_2:

        type: string

        default: ''

 

 

Looking forward to receiving your response,

 

kind regards,

 

Gábor

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]