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-229) Requirements / target filters and subsituable / selectable are too confusing.


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

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

Well I can understand the need, thanks for the clarification. Not a big fan but that's personal ;)

1/ Anyway I agree that target_filter should be renamed at least for the selectable use-case, I also still think that target_filter should exist on the node type requirement (as node type can provide implementation - it may include some contraints that we want to model using target_filters - I know it has been removed but I still see a use-case for it).

2/ Regarding selectable and substitutable I'm not sure if that can be harmonized (maybe not actually) but examples and prose is somehow not clear enough on how this is distinct from selectable:
 - If the substitutable means that the user that defined the template (containing the node to substitute) has also included the substitutable type to use (rather by having the template in the same CSAR and using an import) then I understand how this is different from selectable.
 - If a template with a substitutable node can leave to the orchestrator the ability to find a substitutable template, then I see the need as I have a dangling requirement on this node type and I want a substitute to be provided which sounds to me like selectable. As someone that writes a template I don't care if the substitution is a TOSCA template or a native cloud service provided by the orchestrator, I just need to have it matching the contract I specified and actually the guy that will deploy should choose more than the guy that writes the template. This is my feeling, moreover if an orchestrator has no substitution template but a native service that can match then I want it to be provided.

So if the substitutable means scenario 1 then ok I understand substitutable but still I would like that selectable can be replaced by a substitute node (with added contraints from the selectable filter) in case my orchestrator or target cloud has no ability to provide a selectable match.

3/ Last doubt I have is that I'm not sure to see the use-case of specifying a Compute node as in the hello world (3) when actually Compute is supposed (in my understanding) to be provided by the orchestrator so selectable somehow, I think that people that writes and deploy templates may not be the administrator of a cloud and if a Compute node specifies 
    my_server:
      type: tosca.nodes.Compute
      properties:
        num_cpus: 1
and I just have a flavor with 2 CPUs on my cloud (tenant or whatever deployment target, even bare-metal) I expect the orchestrator to be able to deploy it, so somehow to consider 
    my_server:
      type: tosca.nodes.Compute
      properties:
        num_cpus: 1
as 
    my_server:
      type: tosca.nodes.Compute
      directives: [ selectable ]
      target_filter:
        properties:
          num_cpus: { greater_or_equal: 1 }
Or should it be mapped to 
    my_server:
      type: tosca.nodes.Compute
      directives: [ selectable ]
      target_filter:
        properties:
          num_cpus: { equal: 2 }
And fail to deploy ? If so I would not recommend it for portability purpose (so maybe this should not be the hello world)... But still I feel that this is much more simple to write for an end-user...
What do you think, or am I missing something ?

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


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