[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=59183#comment-59183 ] 

Matthew Rutkowski  commented on TOSCA-229:
------------------------------------------

I understand this sentiment and have been advocating for simplifying the requirement definition as I have been struggling to do going back to last November.  Once we determined that an "abstract node" (i.e., a "selectable" node) was needed (in order to produce models where the other nodes actually had some placeholder to point to) which you would NOT have with a dangling requirement, I thought let me rewrite all the spec.'s use cases in this way... and I did.  However, during the same period I was participating in the Container work group and it became apparent that there are MANY cases where the template (application) author has a paradigm where they simply want to describe their app (Containee) and a few requirements for their host (Container) and it would feel unnatural and awkward for them to actually be forced to create a "selectable" node.  Since then, I have seen this point of view repeated at the SoftwareComponent (Containee) to Compute node (Container) level as well.  That is, I want to describe my application and a few properties for the guest image or memory and not be forced to model the actual Compute node every time (in fact this was in one of our earliest use cases).  

The same argument could be made for Database as well (and a reality with Trove in OpenStack).

Needless to say, over the last few weeks, I have become quite accepting that template/app authors SHOULD have a choice of either describing their abstract requirements within their application node(s) using a target_filter <or> be able to do so using an abstract node (also using the same target_filter).  Then we can show how both can be seamlessly made equivalent/interchangeable when needed and hope I have shown this initially in the WD05, Rev9 YAML spec. in section 11 by adding section 11.1 "Alternative using a node template".

> 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)