Uploaded image for project: 'OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC'
  1. OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
  2. TOSCA-190

CLOSE - CSD02 - Fix grammar for "Constraints" on a Target node of a requirement (Chapter 11)

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: CSD2
    • Fix Version/s: CSD2
    • Component/s: Profile-YAML
    • Labels:
      None
    • Resolution:
      Hide

      Fixed with addition of "node filters" grammar and use on Requirement definitions as a "target filter".

      Show
      Fixed with addition of "node filters" grammar and use on Requirement definitions as a "target filter".

      Description

      Section 11 of WD03, Rev05 has the following example which shows constraints on a requirement. The intent is to constrain the properties used for finding/matching the Target (Compute) node of a relationship. If we still want to allow this, we have no grammar for doing this and need one. Also, the grammar implied by the example perhaps is not sufficient to indicate that these constraints are on the properties of the Target node.

      Here is the example as written:
      node_templates:
      mysql:
      type: tosca.nodes.DBMS.MySQL
      properties:

      1. omitted here for sake of brevity
        requirements:
      • host: tosca.nodes.Compute
        constraints:
      • num_cpus: { in_range: [ 1, 4 ] }
      • mem_size: { greater_or_equal: 2 }
      • os_arch: x86_64
      • os_type: linux
      • os_distribution: ubuntu

        Attachments

          Activity

          Hide
          thomas.spatzier Thomas Spatzier (Inactive) added a comment -

          Ok, so summing up the suggestion would be to go with 'target_filter' which would look something like this:

          mysql:
          type: tosca.nodes.DBMS.MySQL
          properties:

          1. omitted here for sake of brevity
            requirements:
          • host: tosca.nodes.Compute
            target_filter:
          • num_cpus: { in_range: [ 1, 4 ] }
          • mem_size: { greater_or_equal: 2 }
          • os_arch: { equal: x86_64}
          • os_type: { equal: linux}
          • os_distribution: { equal: ubuntu}

          We will have to add a section to the spec that defines the grammer for the target_filter statement. It is basically a list of filter constraints on properties of the entity to be selected. Each entry is a key-value pair where the key is the name of a property and the value is the filter criterion. Note that there can be multiple entries for the same property (since we are using a list), so one would be able to to defined multiple additive criteria.

          I will work with Matt on including this into the spec, if everyone is ok.

          Show
          thomas.spatzier Thomas Spatzier (Inactive) added a comment - Ok, so summing up the suggestion would be to go with 'target_filter' which would look something like this: mysql: type: tosca.nodes.DBMS.MySQL properties: omitted here for sake of brevity requirements: host: tosca.nodes.Compute target_filter: num_cpus: { in_range: [ 1, 4 ] } mem_size: { greater_or_equal: 2 } os_arch: { equal: x86_64} os_type: { equal: linux} os_distribution: { equal: ubuntu} We will have to add a section to the spec that defines the grammer for the target_filter statement. It is basically a list of filter constraints on properties of the entity to be selected. Each entry is a key-value pair where the key is the name of a property and the value is the filter criterion. Note that there can be multiple entries for the same property (since we are using a list), so one would be able to to defined multiple additive criteria. I will work with Matt on including this into the spec, if everyone is ok.
          Hide
          mrutkows Matthew Rutkowski (Inactive) added a comment - - edited

          To extend this to include capabilities we could express it this way:
          mysql:
          type: tosca.nodes.DBMS.MySQL
          properties:

          1. omitted here for sake of brevity
            requirements:
          • host: tosca.nodes.Compute
            target_filter:
          1. node innate
            properties:
          • num_cpus: { in_range: [ 1, 4 ] }
          • mem_size: { greater_or_equal: 2 }
          • os_arch: { equal: x86_64}
          • os_type: { equal: linux}
          • os_distribution: { equal: ubuntu}

            capability:

          • tosca.capabilities.encryption
            properties:
            algorithm: aes
            keylength: 128
          • tosca.capabilities.foo
            properties:
            x: y
          Show
          mrutkows Matthew Rutkowski (Inactive) added a comment - - edited To extend this to include capabilities we could express it this way: mysql: type: tosca.nodes.DBMS.MySQL properties: omitted here for sake of brevity requirements: host: tosca.nodes.Compute target_filter: node innate properties: num_cpus: { in_range: [ 1, 4 ] } mem_size: { greater_or_equal: 2 } os_arch: { equal: x86_64} os_type: { equal: linux} os_distribution: { equal: ubuntu} capability: tosca.capabilities.encryption properties: algorithm: aes keylength: 128 tosca.capabilities.foo properties: x: y
          Hide
          mrutkows Matthew Rutkowski (Inactive) added a comment -

          Jacques: Are the filter expressions an <or> semantic (either or?) if multiple options exist? We need to express combinations at some point.
          Derek: allow target filter to allow multiple, could use conjunctive logic in some way. Current interp. is it is a conjunction. Filters <could> be named at some point
          Jacques: evolutionary approach can be taken.
          Matt: perhaps advantage a regex. (as we have loosely defined so far as an allowed constraint clause)
          Derek: as long as the domain of the property is usable (accessible) to expression it should be allowed.
          Jacques: if only 1 property is truly needed, need a way to express this (or even 1 from an allowed set of values).

          Show
          mrutkows Matthew Rutkowski (Inactive) added a comment - Jacques: Are the filter expressions an <or> semantic (either or?) if multiple options exist? We need to express combinations at some point. Derek: allow target filter to allow multiple, could use conjunctive logic in some way. Current interp. is it is a conjunction. Filters <could> be named at some point Jacques: evolutionary approach can be taken. Matt: perhaps advantage a regex. (as we have loosely defined so far as an allowed constraint clause) Derek: as long as the domain of the property is usable (accessible) to expression it should be allowed. Jacques: if only 1 property is truly needed, need a way to express this (or even 1 from an allowed set of values).
          Hide
          mrutkows Matthew Rutkowski (Inactive) added a comment -

          These discussions seems to make us work on https://issues.oasis-open.org/browse/TOSCA-152 ("Extend Requirement grammar to support "Optional/Best Can" Capability Type matching ") as a base capability to enable more expressivenes of target filters.h

          Show
          mrutkows Matthew Rutkowski (Inactive) added a comment - These discussions seems to make us work on https://issues.oasis-open.org/browse/TOSCA-152 ("Extend Requirement grammar to support "Optional/Best Can" Capability Type matching ") as a base capability to enable more expressivenes of target filters.h
          Hide
          mrutkows Matthew Rutkowski (Inactive) added a comment -

          TOSCA TC approve closure of this issue at the 2014-11-20 meeting. See https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/54595/TOSCA%20Minutes%202014-11-20.docx

          Show
          mrutkows Matthew Rutkowski (Inactive) added a comment - TOSCA TC approve closure of this issue at the 2014-11-20 meeting. See https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/54595/TOSCA%20Minutes%202014-11-20.docx

            People

            • Assignee:
              thomas.spatzier Thomas Spatzier (Inactive)
              Reporter:
              mrutkows Matthew Rutkowski (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: