Hari, Granularity of params and dynamic updates are two different issues. We can file a enhance request for the dynamic updates and community can take its development. While granularity is what I think that is being considered currently.
On 14/04/13 11:22 AM, "Harikrishna Patnala" <harikrishna.patn...@citrix.com> wrote: >Yes Nitin, we need some listener kind of model but for the parameters >that are proposed may not need dynamic update (may be it needed for >storage cleanup interval). >Please correct me if I'm wrong. Can't we proceed normally for the doable >parameters. > >-Harikrishna > >On 11-Apr-2013, at 12:15 PM, Nitin Mehta <nitin.me...@citrix.com> wrote: > >> Mice - This is a great question and I had been wanting to ask the same >>as >> well. From the cloud admin perspective having more granular params >>makes a >> lot of sense in having a much finer control over his cloud, but I >>somehow >> feel that our global configs need some rework. There is a need to have a >> uniform listener model which can dynamically update these values in the >>in >> memory cache. Currently we just load these values during MS start time. >> Also for params which are thread based (like storage.cleanup interval) >>we >> would need to alter the frequency dynamically. >> >> On 11/04/13 10:27 AM, "Mice Xia" <mice_...@tcloudcomputing.com> wrote: >> >>> If we make config parameters granular to zone/cluster/account.. level, >>>do >>> we have to restart mgmt server to take it effect? >>> And it seems this involves a lot of change in codes, is it possible to >>> take this chance and improve global configs so that we can change >>>global >>> config at runtime ( no need to restart mgmt server)? >>> >>> Regards >>> Mice >>> >>> -----Original Message----- >>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] >>> Sent: Thursday, April 11, 2013 11:37 AM >>> To: dev@cloudstack.apache.org >>> Subject: Re: [DISCUSS] Granular Global Parameters >>> >>> >>> >>> 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. >>> >>> We will also need an API to query the config params at these various >>> granularities, that is not mentioned in the FS. >>> >>> -abhi >>> >>> >>> >> >
