OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only

RE: [tosca] Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?

  • 1.  RE: [tosca] Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?

    Posted 08-25-2020 07:53




    Thanks, Tal.
     
    Does this also mean that, up to TOSCA v1.3, the following sentence:


    The string type is the default type when not specified on a parameter or property declaration (3.3 Parameter and property types).
    in practice, only refers to parameter declarations/definitions (where the type keyname is not mandatory) but not to property declarations/definitions?
     
    GÃbor
     
    From: Tal Liron <tliron@redhat.com>

    Sent: Monday, August 24, 2020 4:06 PM
    To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
    Cc: tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>; Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>
    Subject: Re: [tosca] Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?
     


    Because up to TOSCA 1.3 the "type" keyword was listed as mandatory, I would assume that all implementations would
    require you to explicitly specify it, even if it was the same as in the parent. Those that do not I would consider non-compliant.


     


    You are correct that it can be easily derived, which is what we want to fix in TOSCA 2.0. Generally we understand that the "mandatory" column (used to be confusingly called "required") is often not just "yes" or "no" but that in many cases
    it is conditional on inheritance or association to other keywords.


     


    On Mon, Aug 24, 2020 at 6:56 AM Marton, Gabor (Nokia - HU/Budapest) < gabor.marton@nokia.com > wrote:




    Dear TOSCA Experts,
     
    in TOSCA v1.2 and v1.3, is the below
    provider.nodes.Example node type definition valid i.e. does it inherit the type keynames from its parent?
     

    node_types:

      provider.nodes.Base:

        derived_from: tosca.datatypes.Root

        properties:

          property_1:

            type: string

          property_2:

            type: integer

     

      provider.nodes.Example:

        derived_from: provider.nodes.Base

        properties:

          property_1:

            constraints:

              - valid_values: [ value_1, value_2 ]

          property_2:

            constraints:

              - in_range: [ 1, 10 ]
     
    The related parts of TOSCA v1.2/v1.3 are ambiguous:
     


    The type keyname is a mandatory part of a property definition (3.6.10 Property definition).
    The string type is the default type when not specified on a parameter or property declaration (3.3 Parameter and property types).
    Furthermore, I can see no example in the specs that would serve as a precedent for the above example. On the other hand, I guess that inheritance in TOSCA has been meant to work like this.
     
    I understand that in the TOSCA

    v2.0 draft , this aspect is covered in line with the above assumption ( If not refined, usually a keyname/entity definition, is inherited unchanged from the parent type, unless explicitly specified in the rules that it is not inherited ;
    4.2.5.1 General derivation and refinement rules).
     
    I am still asking this question related to
    TOSCA v1.2/v1.3, because implementations differ in this respect, resulting in interoperability issues, turning out too late.
     
    Greetings,
     
    GÃbor