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.
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.
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.
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 }
This logic could already be expressed without your suggestion as follows:
condition:
- or:
- port: { equal: 80 }
- 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 }
The changes in the document should be immediate and straightforward. I could help to write it.
BR,
/Calin
