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

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

I like the fact that the "topology_template" key name is used to specify a group of node templates that logically belong together because they are part of the same application. This makes a lot of sense, but the current proposal makes topology templates somewhat different from other modelable entities in TOSCA. Specifically, topology templates don't have names and don't have types. I would argue again that if we simply allowed for nested node templates, we would avoid the need for new entities that get treated differently and a more "uniform" approach would be possible. Using nested node templates, the example from the latest draft could look as follows:

tosca_definitions_version: tosca_simple_yaml_1_0

node_templates:

  web_application:
    description: Template of an application and its database hosted on a platform
    type: my.types.MyWebApplication
    node_templates:
      my_web_app:
        type: tosca.nodes.WebApplication.MyWebApp
        requirements:
          - host:
              node: my_platform
              capability: web_container
          - database: my_db
  
      my_db:
        type: tosca.nodes.Database.MyDatabase
       requirements:
          - host: [ my_platform, db_container ]

      my_platform:
        type: my.types.MyPlatform
        properties:
          web_port: 8080
          db_port: 9090
          cache_size: 1024

  attributes:
    web_admin_url:
      description: The URL used to administer the Web application.
      value: { get_attribute: [ my_platform, admin_url ] }

In this example, we re-use the node template abstraction to indicate a grouping of nodes that belong together (in this case the "web_application" node template). The result is "nested node template" that gets treated exactly the same by the orchestrator, whether it is deployed stand-alone or whether it is used to substitute some other node of the same type somewhere else.

This approach also eliminates the need for "inputs" and "outputs" on service templates, since their role would be subsumed by the "properties" and "attributes" of node templates. In the example above, the node type my.types.MyWebApplication would include the property definitions for the "web application" node template.  Similarly, the node type would define the attributes, in this case the "web_admin_url" which correspond to what would have been called "outputs" in the alternative model. 

I'm aware of the fact that the "get_attribute" syntax is incorrect. This is an area where extensions are needed since we need a mechanism for node templates to access properties and attributes of nodes they contain, and for contained nodes to access properties and attributes of their "containing" node. 

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