[OASIS Issue Tracker] (TOSCA-229) Requirements / target filters and subsituable / selectable are too confusing.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Matthew Rutkowski  edited comment on TOSCA-229 at 3/19/15 2:00 PM:
-------------------------------------------------------------------

Hi Luc,

Let me share my thoughts for the ideas you have. 

1) I am open to looking at use cases for having the target-filter in the Node Type if there is a compelling use case; however, the editors have agreed that for a proper meta-model it really should only be in the Node Template which I agree with as it would greatly complicate the validation of type-matching as Node Types get subclassed if for no other reason.  

2) Regarding selectable and substitutable .... I too wondered if these 2 concepts (directives) could be harmonized.  However, I have not had a chance to look at what this means and the implications.  So far, I have decided to leave them separate as they come from 2 separate use cases (with different granularities).  That is Substitutable== ServiceTemplate granularity, Selectable==Node Template granularity.  But as you know, Service Templates can be viewed as its own "node"...

3) Completely agree.  Now that we have "selectable" we need to discuss what this means for Compute node and this would alter what we hold up as our "Hello world" use case.


was (Author: mrutkows):
Hi Luc,

Let me share my thoughts for the ideas you have. 

1) I am open to looking at use cases for having the target-filter in the Node Type if there is a compelling use case; however, the editors have agreed that for a proper meta-model it really should only be in the Node Template which I agree with as it would greatly complicate the validation of type-matching as Node Types get subclassed if for no other reason.  

2) Regarding selectable and substitutable .... I too wondered if these 2 concepts (directives) could be harmonized.  However, I have not had a chance to look at what this means and the implications.  So far, I have decided to leave them separate as they come from 2 separate use cases (with different granularities).  That is Substitutable== ServiceTemplate granularity, Selectable==Node Template granularity.  But as you know, Service Templates can be viewed as its own "node"...

3)

> Requirements / target filters and subsituable / selectable are too confusing.
> -----------------------------------------------------------------------------
>
>                 Key: TOSCA-229
>                 URL: https://issues.oasis-open.org/browse/TOSCA-229
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Profile-YAML, Spec - Simple Profile
>            Reporter: Luc Boutier
>
> There is too many notions in the requirements management in the current simple profile document. This makes things very hard to follow while there is actually in my opinion not that many notions to be defined.
> Target filter makes no sense in my opinion in their current placement (on the node template requirements) as they are duplicated with the selectable directive.
> I think it would be more consistent to use the 'selectable' directive in every situations rather than relying on target_filter.
> I also think that selectable pattern is also exactly the same as substitutable from a user perspective as this answer a single need:
>  - I want to link some components to a node that is abstract and I rely on the orchestrator tool to provide a node that match my requirement.
> The fact that the orchestrator provides a selectable or automatic (substitutable) matching (or both with a best-match) is a tool feature and has no place in the specification in my opinion. The matching and quality of matching feature and presentation of the feature is implementor specific.



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