-
Type:
Task
-
Status: Closed
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: CSD2
-
Fix Version/s: CSD2
-
Component/s: Profile-YAML
-
Labels:None
-
Resolution:
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:
- 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
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
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).
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
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
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:
requirements:
target_filter:
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.