cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Configuration variable changes...
Date Mon, 09 Sep 2013 19:41:47 GMT
Daan,

Yeah... I would have preferred to use the first constructor only just because it makes more
sense.  The problem is the second constructor saved me a lot of typing when I convert from
the enums in Config.java to using this class.  So I kept both in there.  I think as long as
it's no ambiguous, it should be okay.  If we want to make sure, we probably should remove
the first constructor.  The number of things I have to type for the first one was just prohibitive.
 :P

As for the multiplier, I figure its usage is probably too small to deserve another constructor.
 If there's a need for it, please go ahead and add another constructor.  

--Alex

> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: Monday, September 9, 2013 12:01 PM
> To: dev
> Subject: Re: Configuration variable changes...
> 
> 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 <daan.hoogland@gmail.com>
> 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 <Alex.Huang@citrix.com>
> 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

Mime
View raw message