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

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

I understand your rationale, but I continue to think that all the extra mechanism and extra complexity of nested service templates and node template substitution can be avoided by simply leveraging existing concepts.  

Let’s take the example from the latest draft:

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:
          node: my_platform
          capability: db_container

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


In this example, we expect that the “my_platform” node template will get substituted by a “nested node template” (since my_platform can’t be orchestrated on its own). However, instead of specifying the “my_platform” node template and then expecting it to get substituted later through nested service template mechanics, we can avoid the need for substation  altogether by making the requirements more general which avoids the need for specifying the my_platform template in the first place. “Substitution” is then replaced by the (existing) concept of allowing these requirements to be fulfilled in different ways. 

Going back to the example, I believe the following service template is equivalent to the one on the draft, but doesn't introduce the “my_platform” template:

node_templates:
  my_web_app:
    type: tosca.nodes.WebApplication.MyWebApp
    requirements:
      - host:
          node: my.types.MyPlatform
          target_filter:
               properties:
                  web_port: { equal : 8080}
                  cach_size: { equal:  1024 }
          capability: web_container
      - database: my_db

  my_db:
    type: tosca.nodes.Database.MyDatabase
    requirements:
      - host:
          node: my.types.MyPlatform
          target_filter:
              properties:
                   db_port : { equal : 9090 }
          capability: db_container

We now no longer have the “my_platform” node template and as a result no longer need substitution. Instead, we need a node template of type my.types.MyPlatform that satisfies the requirements.  Here is where I propose allowing “nested node templates”, which would look as follows:

node_templates:
  my_platform:
    type: my.types.MyPlatform
    node_templates:
      web_server:
        type: tosca.nodes.WebServer.MyWebServer
        properties:
          cache_size: { get_property: cache_size }
        capabilities:
          app_endpoint:
            properties:
              port: { get_property: web_port }

      management_module:
        type: tosca.nodes.WebApplication.MyManagementApp
        requirements:
          host: web_server
        capabilities:
          app_endpoint:
            properties:
              url_path: /admin

      dbms:
        type: tosca.nodes.DBMS
        properties:
          dbms_port: { get_property: db_port }

      server:
        type: tosca.nodes.Compute
        # details omitted for sake of brevity

In this example, composition is specified explicitly by allowing nesting of node_templates key names, but composition could also be generalized by introducing a general-purpose ComposedOf relationship type and then expressing composition in the requirements. This would make composition even more general and would allow for arbitrary levels of nesting. 


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