[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] tosca.nodes.Compute input data questions
The problems that I see are: option 1) - User could not be skilled enough to judge the CPU + RAM + Disk combination and would be better served with a "sizing" object that wraps the complexity of the deployment. Also consider that the end user of a TOSCA file could and should not be the one that wrote it so he has not the knowledge of the correct combination of sizing values in a complex architecture (where do I add the CPU on the web tier, on the DB?) - the combination is not something that can be improvised it has to depend on sizing considerations and each tier need to scale to the needed dimension that that application require (or better that the archect of that application designed) so we need to be able to associate to the "sizing" object a SET of values
option 2) Scalability should be an option for customer (and application designed to dynamically scale) that want to scale ... as a customer I could not want to pay more in the cloud for my application scale out; maybe I'm happy of having a degraded services sometimes since that is my money. But when I choose I planned my investment considering the sizing that thsat application proposed: I went to the catalogue saw application1 that offers 3 sizing, I see I need size 2 and choose that one that means a total of 4 CPU 6 GB ram and 50 GB disk + 1 public IP; I buy all that stuff in the cloud and I go with the deploy. If I'm a public institution I normally plan ahead and have little chances to change it.
My point here is tied to the end usage of the TOSCA standard that is offering an easy approach to deploy in cloud starting from provisioning and we need a way to ease the understanding of these aspects of the deployment customization right in the standard, because is true that I could describe these things outside, but than the standard does not help me enough and I will have to develop something more around it.
My idea is that adding some "definitions" "somewhere" we could allow for parametrizing some SET of values in a way that we can also add the concept of related parameters in an easy way (this can be of use not only in the sizing example). It could be nice if we could chhose betwee different YAML macro but I'm afraid that the specification does not allow it. Another option would be allowing for different "definition file" and some more logic in the tosca-metadata file where we could address the choosing of different deployment solutions - this could also give further meaning to the capabilityes and so on that is: do you prefer the application on MySQL or on PostgreSQL this could send the use on "defnintion that include the MySQL node or the PostgreSQL one in the same csar.
This could be a moment of "TOSCA starter configuration moment" that the orchestrator could present to the end user (if present) in case of multi choice deployment options.
Luca > _________________________________________________________________________ > > Il 5 giugno 2015 alle 1.01 Chris Lauwers <lauwers@ubicity.com> ha scritto: > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]