[OASIS Issue Tracker] (TOSCA-186) DEFER - model composition (Nested templates)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

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

We discussed this yesterday in the editors call and came up with a proposal that could be a good alternative for the current proposal and resolve some issues raised in previous comments.
I would like to share the high-level idea an solicit feedback. If the general direction makes sense for everyone, I would try to work on a concrete proposal for next week.

We think that much of the confusion for users stems from the fact that we loosely put a lot of things in the TOSCA definitions YAML file in a flat structure, i.e. with top-level keywords. We wanted to keep the structure of the YAML as flat as possible so far to keep it simple, but it looks like in the current case a bit more structure could be helpful. Chris' proposal with the nested node_templates section is going in this direction. However, we do not want to allow general nesting of node templates.

So the idea is that we introduce a 'topology_template' section in the YAML file and put the 'node_templates' section under topology_template. This does not change the semantics that we have today, but makes it very clear which part of the YAML file contains the declarative topology model. In addition, topology_template gives us an anchor point for attaching additional information. That additional information would then be the information we need for substitution use cases (substitutable node type, requirement and capability mappings etc.). The semantics would be that the complete topology template can be substituted in for any node template of the declared "substitutable node type". Any keywords we added for mapping purposes would be well scoped to the topology_template.
This is similar to Chris' proposal, but avoid obvious recursive nesting of node templates.

A rough draft snippet would be:

topology_template:
  substitutable_node_type: my.types.MyPlatform
  capability_mappings:
    web_container: [web_server, web_container ] # map cap of MyPlatform to a cap of a contained node
  requirement_mappings:
    # ...
  node_templates:
    web_server: 
      type: tosca.nodes.WebServer.MyWebServer 
      # ...

At the moment, I think that for property and attribute mappings of the substitutable node, we could keep on using the file's inputs and outputs sections, which would also be used when deploying the template standalone. So no additional mapping effort. As an alternative, we could add property_mappings and attribute_mappings explicitly for the substitution case under topology_template.

Feedback is welcome. If there are no major concerns, I would try to come up with a concrete proposal for next weeks YAML WG 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)