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

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

I don't believe the "nested node templates" approach would result in "if-then-else" scenarios. It will actually have quite the opposite effect. With the nested node template approach, every deployable entity, whether it be a single node or an entire topology, would be treated in a uniform fashion. All deployable entities would have a type that specifies properties (aka inputs) and attributes (aka outputs) for entities of that type, and the type would provide lifecycle management interfaces for deploying, managing, and terminating the entity. An orchestrator would simply call the relevant lifecycle management operations on the entity, independent of whether than entity is a single component or an entire application service. No if-then-else required anywhere (of course each type would have to provide specific implementations of lifecycle operations, but that is what abstraction and encapsulation is all about). I think this would also fill a hole in Tosca, since it currently is not possible to specify lifecycle management operations on entire topologies, just on individual nodes.

I'm also not convinced that the substitution concept will be the exception rather than the rule. Unless you're writing demo-ware, most real-world Tosca service templates will be developed in a modular and abstracted fashion where entire subsystems are abstracted in separate (and reusable) topology templates, and application services are made up of several of such subsystems. If that's the case, the common use for topology templates will be for substitution, not for top-level application deployment. 

This also raises a question about the current grammar, by the way. I believe each service template file can only have one single topology_template directive. But what if a service template file imports another file that also has a topology_template? How do we reconcile and/or prevent this?

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