[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] Complex property composition
Dear Tal
Â
Are you sure about this, because the spec says that :
â3.6.11.2 Grammar
Property assignments have the following grammar:
3.6.11.2.1 Short notation:
The following single-line grammar may be used when a simple value assignment is needed:
<property_name>: <property_value> | { <property_value_expression> }
In the above grammars, the pseudo values that appear in angle brackets have the following meaning:
ÂÂÂÂÂÂÂÂÂÂproperty_name:Ârepresents the name of a property that would be used to select a property definition with the same name within on a TOSCA entity (e.g., Node Template, Relationship Template, etc.,) which is declared in its declared type (e.g., a Node Type, Node Template, Capability Type, etc.).ÂÂ
ÂÂÂÂÂÂÂÂÂÂproperty_value,Âproperty_value_expression:Ârepresent the type-compatible value to assign to the named property. Property values may be provided as the result from the evaluation of an _expression_ or a function.
â
Â
For me this definition would mean that the property can either have a fixed value assignment or can be specified via a Tosca function. It does not say anywhere that a property may be constructed from multiple functions.
Would not the possibility of constructing a complex property look like this?
Â
<propertyName>: <property_value> | { <property_value_expression> } | <composite>
<composite>:
ÂÂ <key>: <property_value> | <composite>
, where <key> is a fixed value or { <property_value_expression> }
Â
Â
Maybe Puccini has more advanced capabilities that is described in the specs.
Â
My second problem with this approach is that the parser can not the value of the property
p1:
ÂÂchild1:
ÂÂÂÂget_input: simple_input_child1
value of the child1 is
- get_input: simple_input_child (so a map that has one element with get_input key and simple_input_child value
xor
- The value of the get_input function
In this case the parser is lucky because it can deduct that it is the 2nd Case (because of the type of child1 is string).
However in a generic case when such deduction is not possible and a complex property is constructed from N number of Tosca functions or fixed values.
The complex value may have 2^N variants (exponential), how should we choose which is the actual value.
Here is an example for the problem.
tosca_definitions_version: tosca_simple_yaml_1_2
data_types:
 data_type_1:
ÂÂÂ derived_from: tosca.datatypes.Root
ÂÂÂ properties:
ÂÂÂÂÂ child1:
ÂÂÂÂÂÂÂ type: map
ÂÂÂÂÂ child2:
ÂÂÂÂÂÂÂ type: map
node_types:
 node_type_1:
ÂÂÂ properties:
ÂÂÂÂÂ p1:
ÂÂÂÂÂÂÂ type: data_type_1
topology_template:
 inputs:
ÂÂÂ simple_input_child1:
ÂÂÂÂÂ type: map
ÂÂÂÂÂ default:
ÂÂÂÂÂÂÂ a: b
ÂÂÂ simple_input_child2:
ÂÂÂÂÂ type: map
ÂÂÂÂÂ default:
ÂÂÂÂÂÂÂ c: d
 node_templates:
ÂÂÂ node_template_2:
ÂÂÂÂÂ type: node_type_1
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ p1:
ÂÂÂÂÂÂÂÂÂ child1:
ÂÂÂÂÂÂ ÂÂÂÂÂget_input: simple_input_child1
ÂÂÂÂÂÂÂÂÂ child2:
ÂÂÂÂÂÂÂÂÂÂÂ get_input: simple_input_child2
Â
Â
What is the resolved value of p1:
Â
child1:
 a: b
child2:
 c: d
Â
or
Â
child1:
 get_input: simple_input_child1
child2:
 c: d
Â
or
Â
child1:
 get_input: simple_input_child2
child2:
 c: d
Â
or
Â
child1:
 get_input: simple_input_child1
child2:
 get_input: simple_input_child2
Â
I think that at least some kind of precedence would be required between values and function. For example if the value of a property can be evaluated as a Tosca function, than it is considered to be the value of the tosca function.
Â
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Wednesday, 2021. April 21. 18:26
To: Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com>
Cc: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
Subject: Re: [tosca] Complex property compositionYes, I'm sure it is possible.
You can think of it this way: a data type just like a node template also has properties, so these both accept assigned values in the same way. This implies that you can nest values to any depth.
The situation is less clear when we are dealing with list and map types. However, I think that it likewise should be possible. And for maps, it should even be possible to use function calls for map keys. (Puccini supports all these cases.) Example:
node_types:
 DataNode:
  properties:
   string_map:
    type: map
    entry_schema: string
topology_template:
 node_templates:
  data:
   type: DataNode
   properties:
    string_map:
     Greeting: Hello
     Message: { concat: [ Good, ' ', Day ] }
     { concat: [ Recip, ient ] }: PucciniÂ
On Wed, Apr 21, 2021 at 9:50 AM Nemeth, Denes (Nokia - HU/Budapest) <denes.nemeth@nokia.com> wrote:
Dear Tosca community
Â
Can you help us to clarify the usage of property assigment in node templates specified in
Â
Is is possible to assign parts of complex properties to node templates using property value expressions or not?
Â
Node_template_1 assigns complex_input input to p1 property. There is several examples to this in the specs.
Â
Node_template_2 constucts the value of p1 from multiple input. Is this valid or not?
Â
Many thanks, for the help
Â
tosca_definitions_version: tosca_simple_yaml_1_2
data_types:
 data_type_1:
ÂÂÂ derived_from: tosca.datatypes.Root
ÂÂÂ properties:
ÂÂÂÂÂ child1:
ÂÂÂÂÂÂÂ type: string
ÂÂÂÂÂ child2:
ÂÂÂÂÂÂÂ type: string
node_types:
 node_type_1:
ÂÂÂ properties:
ÂÂÂÂÂ p1:
ÂÂÂÂÂÂÂ type: data_type_1
topology_template:
 inputs:
ÂÂÂ complex_input:
ÂÂÂÂÂ type: data_type_1
ÂÂÂ simple_input_child1:
ÂÂÂÂÂ type: string
ÂÂÂ simple_input_child2:
ÂÂÂÂÂ type: string
 node_templates:
ÂÂÂ node_template_1:
ÂÂÂÂÂ type: node_type_1
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ p1: { get_input: complex_input }
ÂÂÂ node_template_2:
ÂÂÂÂÂ type: node_type_1
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ p1:
ÂÂÂÂÂÂÂÂÂ child1: { get_input: simple_input_child1 }
ÂÂÂÂÂÂÂÂÂ child2: { get_input: simple_input_child2 }
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]