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-186) DEFER - model composition (Nested templates)


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

Thomas Spatzier  commented on TOSCA-186:
----------------------------------------

A couple of thoughts on the last comment:
First of all, I agree that the nested node templates proposal and the topology_template proposal are quite similar, so good to see we are moving towards some alignment.

However, I see a subtle difference: I still think that the nested node templates proposal would be a step too far and suggest general recursive nesting of node templates, even in the same file. Otherwise, we would have to define the grammar like "the node_templates element may contain a nested node_templates element IF the first node_templates element appears top-level in a file" - otherwise we would really allow generic nesting.
Of course, you can achieve the same result with topology_template, but the grammar forces ones to split models up into separate files, and from the top-level file one will only ever see the abstraction of the node template that will be substituted by the topology.

In addition, topology template will be a concept used in all TOSCA YAML; it will be the core of each service template file. So we use the same construct for standalone templates and for nesting. Whereas the nested node templates construct would seem odd for standalone templates.

Regarding the "mapping" section, I don't think this can be addressed separately, because without it substitution, including mapping of properties, attributes and so on will just not work. I will try to see if existing concepts like use of the intrinsic function are applicable and use them as appropriate.
However, we have to keep in mind that the nested topology is a black box - from the point where it is used, only the interface of the substituted node type is visible. And the topology template has to describe at its boundary how internal components fulfil that interface.

I will try to draft something for discussion in tomorrows call.

> DEFER - model composition (Nested templates)
> --------------------------------------------
>
>                 Key: TOSCA-186
>                 URL: https://issues.oasis-open.org/browse/TOSCA-186
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Profile-YAML, Spec - Simple Profile
>            Reporter: Shitao Li
>            Assignee: Thomas Spatzier 
>
> In TOSCA 1.0, it defined the composition of service templates(clause 3.5), which allow a service template to be used as a node template in another service template. 
> In many cases, this is very important and useful feature, especially when describe the complicated service.
> However, in TOSCA-simple-profile-YAML, it seems that this feature does not support.



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