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

Luc Boutier commented on TOSCA-229:
-----------------------------------

Hi Matt,

Here is my need/use-case for point 1)

In the current archives we defined (elk use-case) we are linking the the scripts in the template and not type. This is great but if I want to reuse Nodejs in another context I have to copy all this definition and scripts, this is not very friendly.

In current Profile in order to provide reusable entity I see two options currently to overcome this:
 - Node type with implementation (that seems to still be supported and in my opinion this is the simplest way from a syntax perspective to do that)
 - Substituable template (that's great when I have multiple nodes but for a single node that's actually more complex)

In both situations (keeping the Nodejs example) I need a way to express that my implementation requires a host that is a linux OS (because I wrote sh scripts). That's where the target_filter is supposed to help in my opinion.

Let's discuss that in next meetings (I will make sure I can join ;))

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