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

Thomas Spatzier  commented on TOSCA-186:

Thanks for uploading the document with a sketch of your proposal. I think I understand your proposal, but I still see a number of problems that I already mentioned in previous comments:

1) You removed the node template that is going to be substituted from the top-level template completely. While this is basically ok, it removes some modeling capability: how do I express that both of the other node templates in the top-level file are hosted on the same instance of my_platform? As log as the type and target_filter in your example matches, an orchestrator could attach any matching instance to each of the requirement of the two nodes separately. That mean, we would need some kind of "same as" expression in the requirements section.

2) The grammar allows general nesting of node templates, which I still do not consider a good idea, since it will require more work for model navigation. To prevent general nesting of node templates (beyond the substitution use case) we would need a rule like "if a node template is contained in the node_templates section of a node template, it must not contain another node_templates section" (that's the "if-then-else" kind of coding I mentioned in a previous comment).

3) I am concerned that the additional model navigation functions will introduce more complexity.

I recent discussions with others, it turned out that there might actually be another "substitution like" use case, where one might want to explicitly point to another template resource that is to be used for substitution. Maybe if we clearly identify this other use case, we can think about your proposal or a slight modification again?

Anyway, in parallel I have been working on a revision 12 of WD04 based on Matt's last revision 11. In rev12 I have rewritten section 13 quite a bit since the example seemed really confusing to some people. Instead of introducing a new imaginary node type, I am now showing substitution based on one of the base node types. I have applied my topology_template based proposal throughout complete rev12.
It would be good if everyone could review this as well and see if the proposal looks clearer now.


Finally, I have already mentioned during recent calls that the topology_template based substitution approach is conceptually very close to how nested templates also are implemented in, for example, OpenStack Heat. I strongly believe that adoption in communities like OpenStack (Heat in particular) are important for the success of TOSCA. And I think using mechanisms that they have proven to work instead of introducing different methods will help get adoption. So that is another important aspect in this discussion for me.

> 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

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