For Granular params, I am proposing that we use updateConfiguration command with two additional parameters i.e. scope_type and scope_id. Where scope_type can be zone, account, cluster or pool and scope_id will be the corresponding id of that scope.
We also similarly overload listConfiguration API with these two new params. -abhi On 11/04/13 9:06 AM, "Abhinandan Prateek" <abhinandan.prat...@citrix.com> 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+G >>>l >>>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. > >We will also need an API to query the config params at these various >granularities, that is not mentioned in the FS. > >-abhi > > >
