On Thu, Apr 11, 2013 at 03:36:59AM +0000, Abhinandan Prateek wrote: > > > On 10/04/13 6:30 PM, "David Nalley" <da...@gnsa.us> wrote: > > >On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala > ><harikrishna.patn...@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
