cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: [DISCUSS] Granular Global Parameters
Date Sun, 14 Apr 2013 06:25:54 GMT
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.patnala@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.Mehta@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_xia@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" <david@gnsa.us> wrote:
>>> 
>>>> On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
>>>> <harikrishna.patnala@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
>>> 
>>> 
>>> 
>> 
>


Mime
View raw message