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