cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <>
Subject Re: [DISCUSS] Granular Global Parameters
Date Sun, 14 Apr 2013 06:25:54 GMT
  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"
<> 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
>On 11-Apr-2013, at 12:15 PM, Nitin Mehta <> wrote:
>> Mice - This is a great question and I had been wanting to ask the same
>> 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
>> 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
>> memory cache. Currently we just load these values during MS start time.
>> Also for params which are thread based (like storage.cleanup interval)
>> would need to alter the frequency dynamically.
>> On 11/04/13 10:27 AM, "Mice Xia" <> wrote:
>>> If we make config parameters granular to zone/cluster/account.. level,
>>> 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
>>> config at runtime ( no need to restart mgmt server)?
>>> Regards
>>> Mice
>>> -----Original Message-----
>>> From: Abhinandan Prateek []
>>> Sent: Thursday, April 11, 2013 11:37 AM
>>> To:
>>> Subject: Re: [DISCUSS] Granular Global Parameters
>>> On 10/04/13 6:30 PM, "David Nalley" <> wrote:
>>>> On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
>>>> <> 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: 
>>>>> +Gl
>>>>> obal+Configuration+Parameters
>>>>> The JIRA ticket for tracking is
>>>>> 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
>>>> 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
>>> 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

View raw message