答复: [tosca] [OASIS Issue Tracker] (TOSCA-265) Different flavours of the same Service

[Lishitao <lishitao@huawei.com>]

NFV also has the requirement called deployment flavor, it looks similar with this issue.
I am thinking that how about using Scalable capability to solve this:
1, there is only one topology template needed, it based on the most complicated flavor.
2, in some of the flavor, if some nodes are not needed, then we can set the value of scalable capability to "0", that means the orchestrator does not need to instantiate those node.
3,and in another flavor, we can set the value of scalable capability to the one that we want
4,the flavor can be set as input parameters, the value of scalable capability can be set using get_input()
5,we may need to set another property into scalable capability, maybe called "expected_instances",  or just using ""default_instances" to set the value of scalable capability

-----邮件原件-----
发件人: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] 代表 Chris Lauwers
发送时间: 2015年6月27日 10:51
收件人: OASIS Issues Tracker; tosca@lists.oasis-open.org
主题: RE: [tosca] [OASIS Issue Tracker] (TOSCA-265) Different flavours of the same Service

The Simple Profile spec assumes that your scenario could be satisfied as follows:

- you define one master service template that includes one or more abstract nodes 
- you then define multiple topology templates (for different scale-out architectures) each of which can be used to "substitute" abstract nodes in the master template.

Would this work for your requirement?

Chris

-----Original Message-----
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker
Sent: Thursday, June 25, 2015 12:06 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] [OASIS Issue Tracker] (TOSCA-265) Different flavours of the same Service


    [ https://issues.oasis-open.org/browse/TOSCA-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59929#comment-59929 ] 

Luca Gioppo commented on TOSCA-265:
-----------------------------------

This is linked to the multiple deployment proposal document i placed in the repo.

> Different flavours of the same Service
> --------------------------------------
>
>                 Key: TOSCA-265
>                 URL: https://issues.oasis-open.org/browse/TOSCA-265
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Luca Gioppo
>            Assignee: Luca Gioppo
>
> The use case is:
> 1) I have different "flavours" of the same service that is for example a "transparency portal" composed by Postgresql node +tomcat-lifaray node + apache reverse proxy node as a basic topology for a minimal PA, but I could want to change the topology to scale the service for a bigger PA and I cloud have a cluster of tomcat and a couple of Apache in front with a load balancer.
> As can be seen these are two different topology that cannot be "just scaled" but need different planned topology.
> Logically this is 1 service thus 1 TOSCA file but I have different sizing.
> In the XML spec we have that Definition allows for having more than 1 ServiceTemplate and this is logical since the ServiceTemplate contains all the needed elements to allow for different sizing.
> Is a proper interpretation of the standard or am I stretching it too far?
> I believe that this use case allows the orchestrator to interpret the 
> TOSCA file properly looking at how many ServiceTemplate are there and 
> presenting the end user with a choice of sizing for the service and 
> afterwards the request for the inputs



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php