OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only

Re: Enhancements to the TOSCA data filtering abilities

  • 1.  Re: Enhancements to the TOSCA data filtering abilities

    Posted 12-18-2018 09:09




    Hi,
     
    There are 3 chinks we must iron out:
     


    The addition to or and not in the constraint clause is
    for the purpose of datatype definition and type refinement where condition clauses cannot be used.



    For example there is no way to want to restrict the values of a properties outside an interval
    e.g. less_than 2  or  greater_than 10
    Btw. the and is provided by default by the list, but we could add it for keeping consistence.

     


    Even if adopting Anatoly s 3 rd proposal (which I am in favor of) we cannot do this:
    condition:
      - or:

        - port: { equal: 80 }
        - [compute, mem_size] : { greater_or_equal: 2GB }
     
    Unless we change the node_filter definition in section 3.6.5 that has to start with either properties of capabilities keyword. To do that we could deprecate the use of the previous 2 keywords
    and add the possibility to use conditions in the new form.
    Btw. I m in favor to adopt Anatoly s third proposal also for the potential future addition of special keywords in the list e.g
    [compute, *, mem_size] which could evaluate to: Somewhere in the structure of the capability compute if there is a mem_size
    property then it should have the following constraint
     


    The only reason to keep the assert keyword to use in a long form of an assertion is for the case when there are some properties with the same name as one of the keywords (and, or, not). In such case, there is
    absolutely no way to know what the meaning is.
     
    BR,
    /Calin
     
     

    From: "Katzman, Anatoly" <anatoly.katzman@intl.att.com>
    Date: Tuesday, 18 December 2018 at 02:23
    To: Chris Lauwers <lauwers@ubicity.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


     

    Mine comments added.
     


    From: Chris Lauwers <lauwers@ubicity.com>

    Sent: Saturday, December 15, 2018 12:05 AM
    To: Calin Curescu <calin.curescu@ericsson.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


     
    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.
    [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 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 }
    [AK] Yes!
     
    The changes in the document should be immediate and straightforward. I could help to write it.
     
    BR,
    /Calin