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

 View Only
  • 1.  Inheritance of the "type" keyname: standpoint for TOSCA v1.2/v1.3?

    Posted 08-24-2020 11:56
    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  


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

    Posted 08-24-2020 14:07
    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