Hi Tal,
Letâs try to express concisely what âthe right thingâ is
😊
Iâll go back and review the 2.0 text, but in my opinion here is the spirit of what was intended:
- TOSCA **NEVER** uses defaults for types. The statement about default types in 1.3 was incorrect and has been removed in Version 2.0. In particular, we should
never assume that if no type is specified then âstringâ should be used.
- For property definitions (and attribute definitions) the âtypeâ keyword is mandatory.
- For property (and attribute) refinements, the âtypeâ keyword is not mandatory. If the type is not specified in a refinement, then the type from the ârefinedâ property/attribute definition
is assumed. If a refinement defines a âtypeâ, then that type must be âcompatibleâ with the type of the property/attribute definition that is refined.
- For parameter definitions, the type is optional. The reason for this is that parameter definitions support a short-hand syntax that allows you to provide a value for the parameter.
In most cases, that value will consist of an intrinsic function. If an intrinsic function is used, then the type of the value is the type of the property (or attribute or input) retrieved by that function (which the parser should be able to figure out). If
the value is given inline in the service template (e.g. as a string or an integer) then the type can be derived from the YAML type for that value if the value has a âsimpleâ type. If a complex value is given inline, then we should specify a type so that the
parser can validate that value.
Does anyone disagree with any of this?
Thanks,
Chris
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Wednesday, August 26, 2020 8:20 AM
To: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; 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?
Sorry to belabor this, but TOSCA 1.3 is inconsistent. In the attribute definition (3.6.12.2) "type" is required. In the property definition (3.6.10.2) "type" is required. It's only in parameter definition (3.6.14.1) that it is not required.
Section 3.5.1 is in some ways more confusing than clarifying and is exactly what led us to realize that we need to talk about "refining" in 1.3. The situation is the same in TOSCA 1.2 (different section numbers).
So actually for TOSCA 1.3 the only clarification we got is the addition of 3.6.10.6, which unfortunately is only for properties and not for attributes and parameters. Again, we can make assumptions, but it's these kinds of assumptions that
lead to lack of portability.
The end result is that I would not blame TOSCA implementations up to 1.3 for doing whatever they want with the "type" keyword, as there is conflicting information. I'm sure this is going to be much clearer in TOSCA 2.0 as Calin has done
great work on "refinement" generally.
And by the way, Puccini already does the right thing here. I forgot that I fixed this a long time ago. :)
Thanks for correcting me, Calin! This was really hidden away in 1.3. :) It is unfortunately not mentioned in the Parameter Definition section (3.6.14), although indeed the "required" column for "type" is "no".
I will fix Puccini to conform to this for 1.3 (and stay "required" for <=1.2).
Thanks, Calin.
I overlooked these sections. (I can now recall that we had a related discussion cca. two years ago, after which the refinement-related section was introduced in TOSCA v1.3, but
somehow it slipped from my memory.)
Greetings,
GÃbor
Hi Gabor, Tal,
Both in TOSCA v1.2 and v1.3 we have the following statement:
3.5.1 Required Keynames
The TOSCA metamodel includes complex types (e.g., Node Types, Relationship Types, Capability Types, Data Types, etc.) each of which include their own list of reserved keynames that are sometimes marked as
required. These types may be used to derive other types. These derived types (e.g., child types) do not have to provide required keynames as long as they have been specified in the type they have been derived from (i.e., their parent type).
Now, it does not go into the detail, that this applies also to the entities definitions inside (i.e. propserties,attributes, interfaces, etc.) but it is âassumedâ
😊.
In TOSCA v1.3 we realized that we should be more explicit, so we have for the first time a section on ârefinementsâ that explicitly states what you ask:
3.6.10.6 Refining Property Definitions
TOSCA allows derived types to refine properties defined in base types. A property definition in a derived type is considered a refinement when a property with the same name is already defined in one of the base types for that type.
Property definition refinements use parameter definition grammar rather than
property definition grammar. Specifically, this means the following:
 The type keyname is optional. If no type is specified, the property refinement reuses the type of the property it refines. If a type is specified, the type must be the same as the type of the refined property or it must derive
from the type of the refined property.
 Property definition refinements support the value keyname that specifies a fixed type-compatible value to assign to the property. These value assignments are considered final, meaning that it is not valid to change the property
value later (e.g. using further refinements).
Regarding the default type as string that is valid only for parameters as you mention.
BR/Calin
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.
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
|