On 16/04/13 2:58 PM, "Mice Xia" <mice_...@tcloudcomputing.com> wrote:
>Not meant to stray from the topic, I raised this question because I think >this is a good opportunity to refactor global configs. > >Yes, they are two separate issues, but need think it through before work >in parallel otherwise there will be many code conflicts.. > >+1 for Nitin's proposal: >Firstly introduce an interface and encapsulate the logic of fetching >configs depends on context (zone/pod/cluster/account/..) +1, Hari has made some suggestions, I guess we need to review those and see if they fit in the overall scheme of things. >Then task like implementation of the interface, replacing class >_variables and rewrite some daemon threads can work in parallel >(hopefully) +1 here too. Lets work out the details and take it from there. > >Regards >Mice > >-----Original Message----- >From: Abhinandan Prateek [mailto:cloudst...@aprateek.com] >Sent: Tuesday, April 16, 2013 3:17 PM >To: dev@cloudstack.apache.org >Subject: Re: [DISCUSS] Granular Global Parameters > >On 16/04/13 12:14 PM, "Nitin Mehta" <nitin.me...@citrix.com> wrote: > >>Also as Mice asked do we plan to restart MS to update say config >>changes we make at zone/cluster level ? > >That is how things are currently handled in MS. You need to restart MS >after any config change. > >>For now I would suggest to stop using the class variables (which get >>loaded during the class initiation time) and introduce a generic >>interface with methods (input as name and scope id) to retrieve the >>appropriate value for the config. The implementation of the method >>should ideally use an in memory cache which gets dynamically updated or >>is refreshed every so often(clustered MS can be an issue). But we can >>also use DB for now though it would be highly non performant. In future >>all the configs should start using this. > > >Here we are talking about dynamically updating the config and performance. > >Dynamically updating the config requires a huge volume of change though >they are not complex in nature. > >Performance I will not worry about that much as config updates do not >happen frequently and config is not read often. >As of now most of the config is read when the MS starts. > >The granularity of parameter that the current spec covers is addressing a >different issue. So my hunch will be that we will be Better off putting a >separate spec to address the two other issues of performance and dynamic >update. Probably work can also go in Parallel. > >-abhi > > >> >> >>Some food for thought ? >> >>If we have enough consensus here and the discussion below please go >>ahead and update the FS for the same. >> >>Thanks, >>-Nitin >> >>On 15/04/13 6:23 PM, "Harikrishna Patnala" >><harikrishna.patn...@citrix.com> wrote: >> >>>Yes Abhi I agree with you, this approach will eliminate the usage of >>>multiple APIs. >>> >>>We can specify scope for each configuration parameter both in >>>config.java file and configuration table. >> >> >> >>Don¹t think you need to store scope in the configuration table. You can >>just keep it in Config.java. >> >> >> >>>We will not set the default values during the creation of resource >>>(Zone/cluster/pool/account). >>> >>>Whenever we need to update an entity we call updateConfig API with >>>name, value, scope and resource ID. This does following, >>>- validates the scope of the parameter >>>- checks the resource details table and updates there, if not present >>>then will fetch from the global configuration parameters and create >>>entry in the details table. >>> >>>API: updateConfiguration >>>Parameters: name, value, scope, entityId >>> >>>listConfiguration also fetches based on the scope. >>>API: listConfiguration >>>Parameters: category, name, scope, entityId >>> >>> >>> >>>-Harikrishna >>> >>> >>> >>>On 15-Apr-2013, at 4:36 PM, Abhinandan Prateek >>><cloudst...@aprateek.com<mailto:cloudst...@aprateek.com>> >>> wrote: >>> >>>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<mailto:abhinandan.prat...@citrix.com>> >>>wrote: >>> >>> >>> >>>On 10/04/13 6:30 PM, "David Nalley" >>><da...@gnsa.us<mailto:da...@gnsa.us>> >>>wrote: >>> >>>On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala >>><harikrishna.patn...@citrix.com<mailto: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 >>> >>> >>> >>> >>> >> > >
