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: Re: [tosca] 答复: [tosca] [OASIS Issue Tracker] (TOSCA-265) Different flavours of the same Service


The problem is that from the application point of view different flavours often do not generate compatible topology, that is not that biggest requirements are "just using more machines".
You also configure and deploy things differently: you create clusters, master-slave configuration where on the simple you just had a single node.
Configuration of a JBoss AS in clustered is really different also the apache in the front-end to balance the cluster etc.
 
Is true that you could "try" (if feasible) to create a "catch all" architecture but you are loading on the smallest configurations a burden of complexity that will drag you in the "operation" phase.
I sell more small flavours to my customers and I like to manage in operation simple topology since I can do the investment in mapping a TOSCA file once to get the benefit of reproducing the same simple topology, if for helping the TOSCA writer I have to define a catch all topology where I pay in operation in all my small customers I will stay on puppet or chef and deploy that way or write 2 tosca csar file and live happy.
 
The idea you proposed I see applyed to the grouping of nodes and not to scalability; we can tag nodes with a flavour and this way we can group and use just the nodes selected by the flavour filter.
It could be a little messy for the "human reader/writer" but for me is not a problem no one will HAVE to want to read a TOSCA file as much no one wants to read the "artifacts.xml" of eclipse.
 
Reading better the YAML doc we could use the "groups" sections?
Is again a bit messy since orchestrator should first look at the group to check if there are some "flavour group type" defined and than just read the nodes of the chosen group.

 

I think here we need to decide if the "different flavour" is something we want to model "within" the definition.

If yes than we can brainstorm on where or how.

 

Luca

 >  _________________________________________________________________________

 >  

 >  > Il 29 giugno 2015 alle 3.50 Lishitao <lishitao@huawei.com> ha scritto:

 >  >

 >  >

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

 >  >

 >  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]