OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Enhancements to the TOSCA data filtering abilities

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




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:



  - port:

    - or

      - { equal: 80 }

      - { equal: 431 }


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



  - 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:



  - 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.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]