Alex,
I looked up the constructors and figured it out. next question is
about two of them:
public ConfigKey(Class<T> type, String name, String category,
String defaultValue, String description, boolean isDynamic);
and
public ConfigKey(String category, Class<T> type, String name,
String defaultValue, String description, boolean isDynamic);
should one of them be removed?
makes more sense to add a
public ConfigKey(Class<T> type, String name, String category,
String defaultValue, String description, boolean isDynamic, T
multiplier);
that uses global scope.
On Mon, Sep 9, 2013 at 7:48 PM, Daan Hoogland <[email protected]> wrote:
> Looks great Alex,
>
> One question; Adding a scope or a multiplier is featured on the wiki
> but not specified. Can you add a pointer to it?
>
> Very nice indeed,
> Daan
>
> On Mon, Sep 9, 2013 at 7:20 PM, Alex Huang <[email protected]> wrote:
>> As part of the work to pull apart orchestration from self service, I made
>> some changes to how configuration parameters work. The problem with the
>> current system are as follows:
>>
>> - configuration variables are all stored as enums in Config.java which means
>> plugins have to modify a single file. We established that to be a bad
>> pattern in some earlier thread.
>> - No way to tell during upgrades whether a config variable has become
>> useless or if the defaults have changed.
>> - No way to consistently have variables be dynamically updated.
>> - No way to consistently migrate a global variable to a scoped variable.
>> - No way to use more than one type of storage (db) to store config variables.
>> - Some of the code are still using text strings to retrieve configuration.
>> - No way to consistently validate variables. (although this is not done yet
>> but I described how it can be done in this new framework.)
>>
>> The changes are detailed on wiki [1]. There's a detail list of todo items
>> in ConfigDepotImpl.java if you're interested in picking up any of the work.
>> The old way still works but I recommend we move all new way for new config
>> parameters.
>>
>> If everyone reviewed it all and like how it works then we can remove the old
>> way of how it all works.
>>
>> --Alex
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
