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

Thomas Spatzier  commented on TOSCA-186:
----------------------------------------

Chris, you brought up some points that I agree with and that make sense to me, and others that I disagree with. Let me try to cover all.

First of all, I agree that the introduction of new top-level keywords at service template level is not an optimal solution, especially with we re-use keywords like "capabilities" or "requirements" with a slightly different syntax and semantics than used elsewhere. Ideally, I agree, a service template should be re-usable without any modification. The extra keywords are actually there for allowing an orchestrator to look up candidates that can be used as substitution when a node template of a certain *node type* is used in another template.

About the "implements" keyword: this might not be optimal as well, but I think still covers what happens at runtime: for each node template in a service template, an orchestrator has to go and locate the node type (that provides implementation and deployment artifacts) for instantiating the template. For a "normal" node type, the orchestrator would create some instance representation in its internal data model and then invoke the lifecycle operations defined by the node type. Now in case of a nested template, the orchestrator will also look for a node type denoted by the node template that is being substituted. By means of the "implements" keyword it will find a complete service template that can be used. The only difference is that it will not invoke a node types lifecycle operations, but declarative instantiate the nested template, invoking lifecylce operations of the contained nodes etc.
I actually don't think that this introduces the notion of abstract vs. non-abstract node types. If that is stated in the text, we could change it. At least, we are not introducing anything new. Also for "normal" node types, we already have the case where one node type is just like a base class without any implementation artifacts for operations, and sub-types of the node type then provide the actual implementation.

About the mapping of properties and attributes to inputs and outputs: I don't see a problem with this approach. The template author has to have the ability to decide what data he wants to expose to the outside. The only additional burden is that the defined inputs and outputs have to match the use of properties and attributes in the place where the nested template is used. This concept is widely used and excepted in Heat, for example, and it has proven to work. So sticking to concepts that are used in other communities could help adoption of TOSCA in those communities.
Using the "implements" concept (or we can choose whatever name we like better), it would be trivial to implement validation whether the mapping between inputs/outputs and properties/attributes is correct.

Anyway, an alternative solution to the current top-level keywords approach would be to define the mapping information in a separate file. All it really does is to index a service template for potential re-use in another template.
Or we could think of a way to annotate the place where a nested template is to be used with enough mapping information. The drawback would be that this would likely end up in hardcoding towards one specific nested template, whereas just relying on a node type interface (current proposal) keeps open all aspects of type substitutability.

I disagree with the approach to just introduce general nesting of node templates. The only way this should be done is by having the nested structure defined in its own service template file. I would like avoid allowing users to define nested structures within one service template file (that is how I understand part of your proposal). I think this would bring a lot of additional complexity, since we then have to think, for example, about addressing things within nested structures, which would blow up parts of TOSCA (primarily intrinsic functions, I guess) quite a bit. We really have to have just a "node type" or "instance of a node template of a specific node type" view in the containing template.

No matter what we do, we will still need a way for mapping properties, attributes, requirements, capabilities of the "abstract" (not meant as abstract in object oriented terms, but an abstract view on a more detailed structure) node to elements in a nested template. An that mapping cannot, in my opinion, be done in the containing template since we would hardcode against specific nested templates then. So either it has to be done inside the nested template, or in a separate file.

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