You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Harikrishna Patnala <ha...@citrix.com> on 2013/04/10 13:08:02 UTC
[DISCUSS] Granular Global Parameters
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+Global+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
Re: [DISCUSS] Granular Global Parameters
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Apr 11, 2013 at 03:36:59AM +0000, Abhinandan Prateek 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
> ><ha...@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.
+1 - and keeping it logically distinct will help if / when we spend the
time to transition to a more RESTful API model.
>
> We will also need an API to query the config params at these various
> granularities, that is not mentioned in the FS.
>
> -abhi
Re: [DISCUSS] Granular Global Parameters
Posted by Abhinandan Prateek <Ab...@citrix.com>.
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"
<ha...@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 <Ni...@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" <mi...@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.Prateek@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
>>>> <ha...@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
>>>
>>>
>>>
>>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Harikrishna Patnala <ha...@citrix.com>.
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 <Ni...@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" <mi...@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.Prateek@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
>>> <ha...@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
>>
>>
>>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Nitin Mehta <Ni...@citrix.com>.
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" <mi...@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.Prateek@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
>><ha...@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
>
>
>
RE: [DISCUSS] Granular Global Parameters
Posted by Mice Xia <mi...@tcloudcomputing.com>.
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.Prateek@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
><ha...@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
Re: [DISCUSS] Granular Global Parameters
Posted by Abhinandan Prateek <cl...@aprateek.com>.
On 16/04/13 2:58 PM, "Mice Xia" <mi...@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:cloudstack@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" <Ni...@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"
>><ha...@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
>>><cl...@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"
>>><Ab...@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
>>><ha...@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
>>>
>>>
>>>
>>>
>>>
>>
>
>
RE: [DISCUSS] Granular Global Parameters
Posted by Mice Xia <mi...@tcloudcomputing.com>.
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/..)
Then task like implementation of the interface, replacing class _variables and rewrite some daemon threads can work in parallel (hopefully)
Regards
Mice
-----Original Message-----
From: Abhinandan Prateek [mailto:cloudstack@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" <Ni...@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"
><ha...@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
>><cl...@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"
>><Ab...@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
>><ha...@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
>>
>>
>>
>>
>>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Abhinandan Prateek <cl...@aprateek.com>.
On 16/04/13 12:14 PM, "Nitin Mehta" <Ni...@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"
><ha...@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
>><cl...@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"
>><Ab...@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
>><ha...@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
>>
>>
>>
>>
>>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Nitin Mehta <Ni...@citrix.com>.
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"
<ha...@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
><cl...@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"
><Ab...@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
><ha...@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
>
>
>
>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Harikrishna Patnala <ha...@citrix.com>.
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.
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 <cl...@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" <Ab...@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
<ha...@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
Re: [DISCUSS] Granular Global Parameters
Posted by Abhinandan Prateek <cl...@aprateek.com>.
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" <Ab...@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
>><ha...@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
>
>
>
Re: [DISCUSS] Granular Global Parameters
Posted by Abhinandan Prateek <Ab...@citrix.com>.
On 10/04/13 6:30 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
><ha...@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
Re: [DISCUSS] Granular Global Parameters
Posted by David Nalley <da...@gnsa.us>.
On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
<ha...@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+Global+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.
--David