cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Granular Global Parameters
Date Tue, 16 Apr 2013 01:12:49 GMT
On Thu, Apr 11, 2013 at 03:36:59AM +0000, Abhinandan Prateek wrote:
> 
> 
> On 10/04/13 6:30 PM, "David Nalley" <david@gnsa.us> wrote:
> 
> >On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
> ><harikrishna.patnala@citrix.com> wrote:
> >> Hi all,
> >>
> >> There are many global parameters which are used to set
> >>values/limits/boolean for various operations, but these parameters
> >>effects all zones/clusters/accounts/storage based on the parameter.
> >> Here I would like to discuss on granulising these parameters so that
> >>these parameters can be customised at different levels
> >>(zone/cluster/account/storage).
> >> New APIs are introduced to update these parameters based on the level
> >>listed in the FS below.
> >> During the creation of zone/cluster/account/storage default values for
> >>the granular parameters are set from the normal global parameters and
> >>later these can be updated using the corresponding API.
> >>
> >>
> >> This proposal for Global granular parameters is detailed in the FS
> >>here: 
> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Granular+Gl
> >>obal+Configuration+Parameters
> >> The JIRA ticket for tracking is
> >>https://issues.apache.org/jira/browse/CLOUDSTACK-741
> >>
> >> Please review this and provide me comments/suggestions.
> >>
> >> Thanks
> >> Harikrishna
> >
> >
> >Hi Harikrisha:
> >
> >First - the title is a bit confusing; granular and global seems
> >contradictory. Regardless - this is a great move forward.
> >
> >I don't understand why we would inject a new API command
> >(update{storage,cluster,zone,account}levelparamater) instead of just
> >using updateZone, updateAccount, updateStoragePool, etc. For instance,
> >I would expect that listZone would tell me the status of the
> >zone-level options. So why wouldn't updateZone be capable of setting
> >the options
> 
> 
> Good question. Whether to overload an existing API or create a new one is
> always debatable.
> In this case one of the reason is that the existing update APIs were
> returning a {Zone, Account,..}Response that is not required when you
> change a granular config param. Moreover, all the existing update APIs are
> already heavily overloaded, not a strong reason to avoid further
> overloading though apart from that the response grows in size more you
> overload.

+1 - and keeping it logically distinct will help if / when we spend the
time to transition to a more RESTful API model.

> 
> We will also need an API to query the config params at these various
> granularities, that is not mentioned in the FS.
> 
> -abhi


Mime
View raw message