Hi Denes, Gabor,
We have discussed the subject in the WG and decided to go with the solution you proposed.
We are explicitly saying in TOSCA 2.0 that default values for non-required properties shall not be defined.
If during refinement the property becomes required, then from then on you can provide a default value.
BR/Calin
From: Calin Curescu <
calin.curescu@ericsson.com>
Date: Monday, 18 May 2020 at 15:55
To: "Marton, Gabor (Nokia - HU/Budapest)" <
gabor.marton@nokia.com>, "tosca@lists.oasis-open.org" <
tosca@lists.oasis-open.org>
Cc: "Nemeth, Denes (Nokia - HU/Budapest)" <
denes.nemeth@nokia.com>
Subject: Re: [tosca] Use of properties defaults
Hi Denes, Gabor,
Your observations are fully valid:
Yes, we have not forbidden for non-required properties to have a default value defined, but we say in the specification that it is irrelevant, see section
the default_value is irrelevant for properties that are not required (i.e. property_required is false ) as they will stay undefined , section 3.4.5.4.
This allowed backward compatibility of existing template where somebody might have defined such default value even for non-required properties. Yes, this would mean that if someone changes the required to true then automatically the previously defined default value would start to matter.
But it makes sense that it could be more clear to forbid the definition of default values for non-required properties. I will propose this in the WG discussions.
Second, for my_type_3 definition, the idea is that the required value for p1 still stays false since it was defined as false, and not redefined as true explicitly. But I agree that the explanation: required: if
defined to false in the property definition parent entity type it may be redefined to true ; note that if undefined it is automatically considered as being defined to true is confusing. Since the requirement definition is inherited from the parent,
the if undefined was supposed to refer only to the case that it was never defined in any of the ancestor types
So, I propose we edit the above explanation of refinement rules section 3.4.5.6 for the required keyname as such:
required: if not refined, the definition is inherited from the property definition in the parent entity type; if defined to false in the property definition
in the parent entity type it may be redefined to true ; note that if the required keyword was undefined when the property was defined for the first time, it is considered as having been defined to true .
Best regards,
/Calin
From: <
tosca@lists.oasis-open.org> on behalf of "Marton, Gabor (Nokia - HU/Budapest)" <
gabor.marton@nokia.com>
Date: Monday, 18 May 2020 at 14:39
To: "tosca@lists.oasis-open.org" <
tosca@lists.oasis-open.org>
Cc: "Nemeth, Denes (Nokia - HU/Budapest)" <
denes.nemeth@nokia.com>
Subject: FW: [tosca] Use of properties defaults
Dear Chris, Calin and Arturo,
please find DÃnes questions below (he is not authorized to send mails to the TOSCA list).
Greetings,
GÃbor
From: "Nemeth, Denes (Nokia - HU/Budapest)" <
denes.nemeth@nokia.com >
Date: 2020. May 18., Monday 14:02
To: "
tosca@lists.oasis-open.org " <
tosca@lists.oasis-open.org >
Cc: Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >
Subject: Re: [tosca] Use of properties defaults
Hello Chris and Calin and Arturo
I will try to attach a more concrete example that possibly includes all the corner cases to help the discussions.
Even after reading the 2.0 specs for me it is still not clear what is the exact intention.
Is it possible to define a default for a non-required property? (line in yellow).
If one property becomes required that had a default value, than is it used?
(lines in green)
Maybe if only the required properties shall have default values at all, than life would be simpler.
Cheers Denes
tosca_definitions_version: tosca_simple_yaml_1_0
node_types:
my_type_1:
properties:
p0:
type: string
required: false
p1:
type: string
required: false
default: d1
p2:
type: string
required: true
default: d2
p3:
type: string
required: true
my_type_2:
derived_from: my_type_1
properties:
p 1 :
required: true
default: d4
my_type_3:
derived_from: my_type_1
properties:
p 1 :
#required: true assumed even if not stated since true is the default for required
description: dsad
topology_template:
node_templates:
node1:
type: my_type_1
properties:
p0: a
p1: b
p2: c
p3: d
node2:
type: my_type_1
properties:
# p0 does not have a value
# p1 does not have a value
# p2 has value d2
p3: d # this can not be ommited
node3:
type: my_type_2
properties:
# p0 does not have a value
# p1 has value d4
# p2 has value d2
p3: d # this can not be ommited
node4:
type: my_type_3
properties:
p0: a
# p1 has value d1
# p2 has value d2
p3: d
From: <
tosca@lists.oasis-open.org > on behalf of Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >
Date: 2020. May 18., Monday 9:56
To: "
tosca@lists.oasis-open.org " <
tosca@lists.oasis-open.org >
Subject: [tosca] Use of properties defaults
Hello Chris and Calin,
The use of default values for properties in TOSCA is a recurrent topic of controversy in ETSI NFV SOL.
What has been stated in the TOSCA Language WG is that default values are only meaningful for properties that are defined as required = true e.g. in a node type definition.
A default value for a property that is defined as required = false in a node type definition is irrelevant and it will never be used: a node template either provides a property assignment for that property (in which case
the default value is overrriden) or it does not provide a property assignment (in which case the property is not used in this node template).
Unfortunately this is not explicitly written in the TOSCA spec. Furthermore, there is at least one example in 3.4.5.7 in TOSCA 2.0 with a default value for a property which has required = false. In TOSCA 1.3 there are
a few more examples but these are in the profile part.
Can we discuss this topic briefly tomorrow and add a clarification in TOSCA about the use of defaults?
Best regards,
Arturo