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: [OASIS Issue Tracker] (TOSCA-190) Fix grammar for "Constraints" on a Target node of a requirement (Chapter 11)


    [ https://issues.oasis-open.org/browse/TOSCA-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47541#comment-47541 ] 

Thomas Spatzier  edited comment on TOSCA-190 at 10/8/14 8:05 AM:
-----------------------------------------------------------------

I like Chris' suggestion of using a different keyword for this use case, i.e. not calling it 'constraints'. However, I am not sure if 'search_criteria' is the right term, since it might be that the required entity does not exist but has to be created. That is, an orchestrator _might_ search for something existing to match the requirement OR if nothing is found create something appropriate.
So what about 'filter' or 'target_filter', or 'selection_criteria'? Anyway, we can wait for some more good suggestions and select one if everyone agrees that 'constraints' is not what we want.

Regarding syntax, I think Chris' suggestion makes sense and is crisp. I was first thinking about using the exact same syntax of constraints which would have been

mysql:
    type: tosca.nodes.DBMS.MySQL
    properties:
      # omitted here for sake of brevity
    requirements:
      - host: tosca.nodes.Compute
        search_criteria:
          num_cpus:
             constraints:
               - in_range: [ 1, 4 ]
          mem_size:
              constraints.
               - greater_or_equal: 2

but that is obviously much more verbose without much value add (would allow for having more than one use of the same constraint type for a property, but I don't see a compelling reason).


was (Author: thomas.spatzier):
I like Chris' suggestion of using a different keyword for this use case, i.e. not calling it 'constraints'. However, I am not sure if 'search_criteria' is the right term, since it might be that the required entity does not exist but has to be created. That is, an orchestrator _might_ search for something existing to match the requirement OR if nothing is found create something appropriate.
So what about 'filter' or 'target_filter', or 'selection_criteria'? Anyway, we can wait for some more good suggestions and select one if everyone agrees that 'constraints' is not what we want.

Regarding syntax, I think Chris' suggestion makes sense and is crisp. I was first thinking about using the exact same syntax of constraints which would have been

mysql:
    type: tosca.nodes.DBMS.MySQL
    properties:
      # omitted here for sake of brevity
    requirements:
      - host: tosca.nodes.Compute
        search_criteria:
          num_cpus:
             constraints:
               - in_range: [ 1, 4 ]
          mem_size:
               - greater_or_equal: 2

but that is obviously much more verbose without much value add (would allow for having more than one use of the same constraint type for a property, but I don't see a compelling reason).

> Fix grammar for "Constraints" on a Target node of a requirement  (Chapter 11)
> -----------------------------------------------------------------------------
>
>                 Key: TOSCA-190
>                 URL: https://issues.oasis-open.org/browse/TOSCA-190
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Task
>          Components: Profile-YAML
>    Affects Versions: CSD03
>            Reporter: Matthew Rutkowski 
>            Assignee: Thomas Spatzier 
>            Priority: Critical
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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