Yes, we are in complete agreement, although to be even more correct:
Condition clauses recurse until they are terminated by primitive assertion clauses rather than constraint clauses. An assertion clause consists of
a property/attribute name with an associated constraint clause.
I don t recommend changing constraint clauses for now, although Calin suggested that constraint clauses themselves could benefit from adding Boolean operators.
Chris
From: Katzman, Anatoly <
anatoly.katzman@intl.att.com>
Sent: Monday, December 17, 2018 5:03 PM
To: Chris Lauwers <
lauwers@ubicity.com>; Calin Curescu <
calin.curescu@ericsson.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;
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
A careless find-an-replace sweep across the whole document to make conditions appear instead of constraints can break our grammar. For example, today a condition clause is defined recursively,
and this definition recursion normally gets terminated by primitive constraint clauses. We must not make this recursion infinite.
I am now working on a more elaborated response, will send it out shortly.
From: Chris Lauwers <
lauwers@ubicity.com >
Sent: Friday, December 14, 2018 7:14 AM
To: Katzman, Anatoly <
anatoly.katzman@intl.att.com >; Calin Curescu <
calin.curescu@ericsson.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 ;
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 Anatoly,
Could you clarify what exactly you re concerned about when you say make sure this replacement of constraints by condition does not leak beyond the node_filter definition ?
Thanks,
Chris
From: Katzman, Anatoly <
anatoly.katzman@intl.att.com >
Sent: Thursday, December 13, 2018 9:10 AM
To: Calin Curescu <
calin.curescu@ericsson.com >; Chris Lauwers <
lauwers@ubicity.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
This is an absolutely beautiful idea, but we have to be careful here. Conditions and constraints are not the same. Maybe this change can wait for 1.4? Or, at least, make sure that this replacement
of constraints by condition does not leak beyond the node_filter definition?
From: Calin Curescu <
calin.curescu@ericsson.com >
Sent: Thursday, December 13, 2018 11:53 AM
To: Chris Lauwers <
lauwers@ubicity.com >; Katzman, Anatoly <
anatoly.katzman@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. 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.
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.
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.
The changes in the document should be immediate and straightforward. I could help to write it.
BR,
/Calin
From: Chris Lauwers <
lauwers@ubicity.com >
Date: Wednesday, 12 December 2018 at 03:26
To: "Katzman, Anatoly" <
ak435s@intl.att.com >, Calin Curescu <
calin.curescu@ericsson.com >, "NOSHPITZ, CLAUDE" <
cn5542@att.com >,
"
alex.vul@intel.com " <
alex.vul@intel.com >, Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com >, "
lishitao@huawei.com "
<
lishitao@huawei.com >, "
ljlamers@vmware.com " <
ljlamers@vmware.com >, "
mrutkows@us.ibm.com " <
mrutkows@us.ibm.com >,
"
Paul.Lipton@ca.com " <
Paul.Lipton@ca.com >, "
priya.g@netcracker.com " <
priya.g@netcracker.com >,
Steve Baillargeon <
steve.baillargeon@ericsson.com >, "
thinh.nguyenphu@nokia.com " <
thinh.nguyenphu@nokia.com >, "
dmytro.gassanov@NetCracker.com "
<
dmytro.gassanov@netcracker.com >, "
don.deel@netapp.com " <
don.deel@netapp.com >, "
dpalma@vnomic.com "
<
dpalma@vnomic.com >, "SHADMI, DAVID" <
ds200p@att.com >, "
hsurti@cisco.com " <
hsurti@cisco.com >, "
ifat.afek@alcatel-lucent.com "
<
ifat.afek@alcatel-lucent.com >, "
JDurand@us.fujitsu.com " <
JDurand@us.fujitsu.com >, "
jeremy@gigaspaces.com "
<
jeremy@gigaspaces.com >, "
jim.hunter@ca.com " <
jim.hunter@ca.com >, "
jpackett@us.ibm.com " <
jpackett@us.ibm.com >,
"
kraman@redhat.com " <
kraman@redhat.com >, "
luca.gioppo@csi.it " <
luca.gioppo@csi.it >, "
rpenta@redhat.com "
<
rpenta@redhat.com >, "
xavier.degenne@fastconnect.fr " <
xavier.degenne@fastconnect.fr >, "
zhao.huabing@zte.com.cn "
<
zhao.huabing@zte.com.cn >
Cc: "
tosca@lists.oasis-open.org " <
tosca@lists.oasis-open.org >
Subject: RE: Enhancements to the TOSCA data filtering abilities
By the way, as I think about this more, it seems to me that there is no reason why node filters should use condition clauses (rather than constraint clauses). For example, if I wanted a node filter
that says: I want a Ubuntu host with 8G of memory or a CentOS host with 4G of memory . I don t think I can express that using just constraint clauses (even when we add Boolean operators to constraints) since we need constraints that combine multiple properties.
Using condition clauses in node filters would solve this problem.
Thanks,
Chris
From: Katzman, Anatoly <
ak435s@intl.att.com >
Sent: Sunday, September 23, 2018 6:20 AM
To: Calin Curescu <
calin.curescu@ericsson.com >; Chris Lauwers <
lauwers@ubicity.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 Subject: RE: Enhancements to the TOSCA data filtering abilities
Hi Calin,
Thank you for the feedback, really encouraging.
Regarding the new self-reflecting attributes I think it is a good addition and that it deserves a separate proposal and a separate discussion thread