[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] [OASIS Issue Tracker] (TOSCA-265) Different flavours of the same Service
|
I agree that we should support multiple (named) topology templates. Since service templates can import other service templates, and each service template could
have a topology template, one could accidentally end up with multiple topology templates anyway. We should anticipate this an allow multiple topology templates within a service template. From: Luca Gioppo [mailto:luca.gioppo@csi.it]
I do not understand where these are defined. In the simple profile there is just one topology_template section or it can be more than one?
In the option of having all the nodes in the same template there should be the option to "group" them in a logical group representing the "service level" but this could be a mess in readability.
Also The need is to allow the catalogue/marketplace to read the TOSCA file and present the end user the choice ("do you want to buy/install the "big city" or the "small municipality" version/flavour of the service?")
To maximize readability I think that a different topology_template section (thus having more than one could be better and more clean).
Abstract nodes could be an overkill and not so simple, in my opinion.
Luca > _________________________________________________________________________ > > > Il 27 giugno 2015 alle 4.51 Chris Lauwers <lauwers@ubicity.com> ha scritto: > > > > > > 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 > > > > > > > > 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]