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

Chris Lauwers commented on TOSCA-186:
-------------------------------------

I think this “topology_template” idea is a step in the right direction since it introduces an entire topology as a “first class entity” that can be managed as a unit, which is what the “nested node template” proposal also argues for.

In fact, I would go as far as saying that the 2 proposals are semantically equivalent. Let’s look at the snipped from the proposal:

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 
      # ...

By just replacing the second line, this would get turned into the “nested node templates” proposal:

nested_topology_template:
  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 
      # ...

The rest of the snippet consists of syntax for managing mappings, which in my opinion should be considered and discussed separately from the basic “nesting” concept.

Thomas states that “… we don’t want to allow general nesting of node templates…” but I don’t see how this can be avoided using the “topology_template” concept. As far as I can tell, there is nothing that would prevent me from taking a node_template contained in a topology_template and substituting that node template using a second topology_template defined somewhere else, as long as that second topology_template is declared as a “substitutable_node_type” for the node_template specified in the first topology_template. This effectively results in arbitrary nesting of node templates.

Furthermore, I assume that “topology templates” would be implemented using the same “proxy node templates” that were proposed before, so the implementation would in fact be a “nested node template” implementation as well.

So, given that “topology templates” semantically behave like “nested node templates”, and that any implementation of “topology templates” would likely use “nested node templates” internally anyway, I would again recommend that we make all of this explicit and expose it in the model. This would avoid the need for extra concepts (such as topology_templates”) in the model. In my opinion, the best way to keep the Simple Profile simple is exposing a simple model to the end user, and a key way to keep the user model simple is by limiting the number of abstractions the user has to get familiar with. Modeling everything as “node templates” would accomplish this goal.

On a related note, using the same “simplicity” argument, I would suggest that we manage “mappings” using existing “model navigation” concepts, i.e. by extending the “get_property” and “get_attribute” functions with “get_capability” and “get_requirement” functions as necessary (rather than by introducing a new “mapping” concept). But as I noted earlier, this discussion is secondary to getting agreement on the basic nesting abstractions.

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