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

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

If I understand correctly, the general idea behind “nested service templates” is that one could take a previously-defined service template and “embed” it in its entirety as a building block into a new service template to allow abstraction, reuse, etc. In practice, however, it appears that things don’t actually work that way:

•	One can’t just take any arbitrary service template and embed it as-is. Instead, the service template that is to be embedded has to be aware of the fact that it is intended to be embeddable as follows:
-	It has to include an “implements” key name that identifies it as an embeddable service template.
-	Conversely, it’s not clear if an “embeddable” service template still has the ability to stand on its own, i.e. can an embeddable service template be orchestrated without an “embedding” service template?
•	The “implements” key name is misleading at best and incorrect at worst: 
-	It suggests that the service template provides an implementation for the “abstract node type” identified by the “implements” key name. However, there is nothing in TOSCA that defines some node types as abstract, and as far as I can tell there is no difference between fully-defined node types and node types that require an implementation.
-	If a “nested service template” provides an implementation for an abstract node type, then that would make a “nested service template” another Node Type. In reality, however, nested service templates behave like “node templates”, not like “node types”. They provide entities that can be orchestrated using the Node Type specified in the “implements” key name. This makes a nested service template an “instance” of the Node Type to be implemented, not an “implementation” for that node type.
•	Since nested service templates behave like node templates, they will need to support all the functionality supported by node templates:
-	This necessitated the introduction of “capabilities” as a new top-level key name on service templates. The grammar and semantics of this “capabilities” key name is different from capabilities definitions in other parts of the spec, since “service template capabilities” need to be mapped onto capabilities from the node templates contained in the service template.
-	For symmetry reasons, “requirements” will need to get introduced as well. 
-	Node templates need “properties” and “attributes”. Nested service templates provide these by carefully mapping properties of contained node templates into “inputs” of the service template and mapping attributes of contained node templates into “outputs” of the service template. This mapping is a manual process and is error prone.

In summary, I believe the “nested templates” approach being proposed introduces additional complexities without making re-use easier:
•	It doesn’t really accomplish the goal of service template “re-use” since service templates have to be modified to be reusable
•	It will result in user confusion since the model being exposed (implementation of abstract types) doesn’t match reality (instantiation of simple types). 
•	It introduces additional complexity because of the need for additional key names at the service template level
•	It is error prone because node template properties and attributes need to be mapped correctly on service template inputs and outputs

Based on these concerns, I would like to propose an alternative approach that owes up to what we’re already doing anyway:  if nested service templates in reality act exactly like node templates, let’s make this explicit, and let’s allow for node templates to be nested (rather than service templates). This means that a node template could contain a set of other node templates. 

I think this approach has a number of obvious advantages:
•	We would no longer need the “implements” key name, which would eliminate user confusion about what this really is. We would also no longer suggest that there is somehow a difference between “abstract” node types and “regular” node types. 
•	It would simplify orchestrators, since I assume orchestrators would have to create some sort of “dummy” node template to correspond to a nested service template anyway. Using “nested node templates” we would make this extra node template explicit. 
•	It would avoid the need for new key names on service templates, since we would just use existing key names on node templates.
•	We would use regular property and attribute definitions on node templates, rather than having to define inputs and outputs on service templates and then having to map those.


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