Also as Mice asked do we plan to restart MS to update say config changes we make at zone/cluster level ? 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.
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 > > > > >
