Re: Enhancements to the TOSCA data filtering abilities

Hi,

 

I think there is a difference between condition clauses and constraint clauses and it should stay so. Actually
 condition clauses use constraint clauses for each property or attribute they apply to.

More comments inline in the mail below.

 

BR,

/Calin

 

From: "Katzman, Anatoly" <>

Date: Tuesday, 18 December 2018 at 14:47

To: 'Chris Lauwers' <>, Calin Curescu <>, "NOSHPITZ, CLAUDE" <>, "''" <>, Arturo Martin De Nicolas <>, "''"
 <>, "''" <>, "''" <>, "''" <>, "''" <>, Steve Baillargeon <>,
 "''" <>, "''" <>, "''" <>, "''" <>, "SHADMI, DAVID" <>, "''"
 <>, "''" <>, "''" <>, "''" <>, "''" <>, "''"
 <>, "''" <>, "''" <>, "''" <>, "''" <>, "''" <>

Cc: "''" <>

Subject: RE: Enhancements to the TOSCA data filtering abilities

 

PS: 

>>>> 

What are these âsomeâ tables? Well, the Node filter definition (3.6.5) will gain significantly from the change. So in the Node Filter Definition section, I would add the âconditionâ keyname
 with a reference to the condition clause definition, and this is in addition to already existing keynames âpropertiesâ and âcapabilitiesâ.

This is the part where conditions clauses come in. Regarding âpropertiesâ
 and âcapabilitiesâ, I think we should deprecate them and use Anatolyâs third proposal based on the format of the get_property
 function.

 

I am less sure about other tables, such as Property filter definition (3.6.4) , Property definition (3.6.10), Schema definition (3.6.9), Data type (), and I probably forgot
 a few. If we decide to change them in 1.3, than another question is whether to redefine the existing âconstraintsâ keyname or introduce the less confusing âconditionâ instead?

Here we need to keep the constraint clauses since they refer to only on ONE property (the one that is defined).
 Condition clauses cannot be used.

I also think that âorâ and ânotâ need to be introduced here since we cannot use the condition clauses.

<<<< 

I took a second look on the grammars of these four tables, and everything looks safer in the morning
😊. Now I do want to extend the change to these clauses in 1.3. In all four clauses, I suggest to keep using the keyname âconstraintsâ
 to start the condition definition. 

 

From: Katzman, Anatoly

Sent: Tuesday, December 18, 2018 3:23 AM

To: Chris Lauwers <>; Calin Curescu <>; NOSHPITZ, CLAUDE <>; ; Arturo Martin De Nicolas <>; ; ; ;
 ; ; Steve Baillargeon <>; ; ; ; ; SHADMI, DAVID <>; ; ;
 ; ; ; ; ; ; ; ; 

Cc: 

Subject: RE: Enhancements to the TOSCA data filtering abilities

 

Mine comments added.

 

From: Chris Lauwers <>

Sent: Saturday, December 15, 2018 12:05 AM

To: Calin Curescu <>; Katzman, Anatoly <>; NOSHPITZ, CLAUDE <>;
; Arturo Martin De Nicolas <>;
; 
; ;
; 
; Steve Baillargeon <>;
; 
; ;
; SHADMI, DAVID <>;
; 
; ;
; 
; ;
; 
; ;
;


Cc: 

Subject: RE: Enhancements to the TOSCA data filtering abilities

 

Comments in-line

 

From: Calin Curescu <>

Sent: Thursday, December 13, 2018 1:53 AM

To: Chris Lauwers <>; Katzman, Anatoly <>; NOSHPITZ, CLAUDE <>;
; Arturo Martin De Nicolas <>;
; 
; ;
; 
; Steve Baillargeon <>;
; 
; ;
; SHADMI, DAVID <>;
; 
; ;
; 
; ;
; 
; ;
;


Cc: 

Subject: Re: Enhancements to the TOSCA data filtering abilities

 

Hi,

 

I agree that we should use
condition clauses in the node_filter instead of constraint clauses. This will allow us to put an âorâ or a ânotâ in front of several attributes.

Moreover, by using the âdirect assertion definitionâ when specifying it, the condition clause becomes undistinguishable from a constraint clause.

 

Actually, to be technical correct, I would rephrase this as follows:. The syntax for condition clauses looks as follows (assuming we deprecate the âassertâ keyword):

 

condition_clause: and_clause | or_clause | not_clause | list of assertion_clause

or_clause : âor:â + list of condition_clause

and_clause: âandâ + list of condition_clause

not_clause: ânotâ + list of condition_clause

assertion_clause: <property_name:> +  list of constraint_clause

 

The syntax for property filter clauses looks as follows:

 

property_filter: <property_name:> + list of constraint_clause

 

What this means, then, is that the assertion clause and the property filter clause look exactly the same (assuming again that we deprecate the âassertâ keyword). If in addition, we allowed Boolean
 operators in node_filters, then a node filter would effectively consist of a condition clause. Constraint clauses would still look different.

[AK] Right. A condition clause is generally a complex thing that can include nested conditions, while a constraint clause specifies a primitive predicate. A constraint is so primitive that
 even the value it is applied to is specified outside of it. 

constraint_clause: greater_than | less_than | ...

              

Which means that all the existing specifications stay valid. We just add the possibility to put an âandâ âorâ or ânotâ before several properties/attributes, from now on.

 

Unless anyone objects, I will obsolete the âassertâ keyword in condition clauses.

[AK] I objected in the past, because I thought it would be useful in the future for applying custom predicates. Now I withdraw my objections.

 

Also within the constraint clause it is useful to have âorâ and ânotâ to be able to express better constraints. This is simple, just by adding the âandâ, âorâ, and ânotâ to the constraints
 keyword tables. Again, this will extend the constraint clause, with all that is already written staying valid.

[AK] I think we still need the constraint clause (3.6.3) in its existing form, at least to use it (as part of the property assertion clause) to terminate recursively defined conditions.
 What you call a âbetter constraintâ is actually a condition clause (3.6.25), so instead of redefining the constraint clause itself, I would change or add references from some of the keyname tables.

What are these âsomeâ tables? Well, the Node filter definition (3.6.5) will gain significantly from the change. So in the Node Filter Definition section, I would add the âconditionâ keyname
 with a reference to the condition clause definition, and this is in addition to already existing keynames âpropertiesâ and âcapabilitiesâ. I am less sure about other tables, such as Property filter definition (3.6.4) , Property definition (3.6.10), Schema
 definition (3.6.9), Data type (), and I probably forgot a few. If we decide to change them in 1.3, than another question is whether to redefine the existing âconstraintsâ keyname or introduce the less confusing âconditionâ instead?

Yes, this would be simple to do, but Iâm not sure it adds a whole lot of value. For example, letâs look at the following example which would become possible with your suggestion:

 

condition:

  - port:

    - or

      - { equal: 80 }

      - { equal: 431 }

[AK] This one will not work. After a property name, the grammar expects a list of primitive constraints, not a condition.

 

This logic could already be expressed without your suggestion as follows:

 

condition:

  - or:

    - port: { equal: 80 }

    - port: { equal: 431 }

[AK] I really like this new syntax, it is really powerful. It allows to combine multiple properties and sub-properties in one condition. Here is an even better example:

condition:

  - or:

and:

    - protocol: { equal: http }

    - port: { equal: 80 }

and:

    - protocol: { equal: https }

    - port: { equal: 431 }

 

Would we create confusion by giving template designers two different ways to accomplish the same thing?

 

The only thing that we still cannot do within a node_filter is to have an âorâ between normal properties and properties within a capability definition. But this is a small price
 to pay for backwards compatibility.

 

Yes, but that could be accomplished if we adopted Anatolyâs 3rd proposal, as follows. Letâs assume a node has a âportâ property and a âcomputeâ capability. We could create a logic _expression_
 as follows:

 

condition:

  - or:

    - port: { equal: 80 }

    - [compute, mem_size] : { greater_or_equal: 2GB }

[AK] Yes!

 

The changes in the document should be immediate and straightforward. I could help to write it.

 

BR,

/Calin