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

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

Regarding your second snippet in the last comment (the one without the my_platform node template), it is right that this is equivalent. And I have thought about such an approach as well. However, for more complex use cases where we have multiple substitutable node templates (according to the original proposal) and we want want to express that some node connect to one of those, and others to another substitutable node, we would need additional syntax to express this.
Explicitly having the substitutable nodes in the model would allow us to use the existing concept of relationships to capture such constraints.

Also, for your 3rd snippet above (the one with the nested node_templates), what is missing is a way to express which of the contained node templates actually provide the capabilities of the MyPlatform node type, and which of the contained node templates' properties are exposed as the properties of MyPlatform etc. So if we think this thru, this gets more complicated.

And I still am not in favor of allowing node template nesting, because this will require additional syntax for navigating the model.

Furthermore, I do not understand the statement you make at the beginning that the my_platform node template cannot be orchestrated on its own. I think it can well be orchestrated. The only difference is that it's create operation will not result in the invocation of an implementation artifact, but in the creation of a nested topology defined in the nested template. The way to implement this would be via some kind of proxy node template instance that provides the abstract view, which is backed by the nested topology. For someone working with the top level instance, by default only the abstracted "proxy node" would be visible, with the option to drill down in the nested structure. This has been implemented elsewhere and been proven to work well.

##########

Maybe let's try to restate some requirements and then see how we could come to a solution. Here is what I see from my perspective:

R1: ability to define detailed structures for subsystems in separate, re-usable service templates
R2: the re-usable templates should be valid on their own, and deployable on their own (standalone)
R3: node templates in a top-level service template should be able to be substituted by a nested template
       (as explained above, this will allow us to capture relations thru existing mechanisms)
R4: substitution must not be hard-coded, but allow for selecting among a set of options

I think R3 and R4 call for node type based substitutability. And with that I take the following from recent discussions with others:

R5: a service template that "implements" a node type should expose all the characteristics of a node type (properties, attributes, requirements, capabilities)

Is this about what others also see as requirements?

If so, the current proposal should roughly be the right direction. If we want to avoid new top-level keywords, we could come up with a separate file for defining the mapping of service templates to node types as I suggested earlier. The key question is really whether we want to do substitution based on node types.

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