Comments in-line
From: Calin Curescu <
calin.curescu@ericsson.com>
Sent: Thursday, December 13, 2018 1:53 AM
To: Chris Lauwers <
lauwers@ubicity.com>; Katzman, Anatoly <
ak435s@intl.att.com>; NOSHPITZ, CLAUDE <
cn5542@att.com>;
alex.vul@intel.com; Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com>;
lishitao@huawei.com;
ljlamers@vmware.com;
mrutkows@us.ibm.com;
Paul.Lipton@ca.com;
priya.g@netcracker.com; Steve Baillargeon <
steve.baillargeon@ericsson.com>;
thinh.nguyenphu@nokia.com;
dmytro.gassanov@NetCracker.com;
don.deel@netapp.com;
dpalma@vnomic.com; SHADMI, DAVID <
ds200p@att.com>;
hsurti@cisco.com;
ifat.afek@alcatel-lucent.com;
JDurand@us.fujitsu.com;
jeremy@gigaspaces.com;
jim.hunter@ca.com;
jpackett@us.ibm.com;
kraman@redhat.com;
luca.gioppo@csi.it;
rpenta@redhat.com;
xavier.degenne@fastconnect.fr;
zhao.huabing@zte.com.cn Cc:
tosca@lists.oasis-open.org 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 3 rd 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