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 >> >> >> >
