Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of darren.s.shepherd@gmail.com
 designates 209.85.160.49 as permitted sender)
Message-ID: <522E2896.70603@gmail.com>
Date: Mon, 09 Sep 2013 12:59:18 -0700
From: Darren Shepherd <darren.s.shepherd@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: dev@cloudstack.apache.org
Subject: Re: Configuration variable changes...
References: <20CF38CB4385CE4D9D1558D52A0FC0581115B1@SJCPEX01CL03.citrite.net>
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC0581115B1@SJCPEX01CL03.citrite.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/09/2013 10:20 AM, Alex Huang 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
>

Can the generic API be

	<T> ConfigKey<T> get(String paramName, Class<T> type);

Just to be a little easier to use.  I know the method is discouraged, 
but I do so some places it would be useful.  Besides that I like it. 
The contract is simple enough that the implementation can become quite 
flexible.

Scoped values seems a little strange though.  Why do you define the 
scope in the key?  Why wouldn't you pass the scope when you call 
valueIn?  Its seems a bit odd.  Because as the caller, you need to know 
what the Long is (is it a zone id, pool id, etc.).  So it seems more 
natural to pass valueIn(Scope.Zone, 42) because it is very explicit to 
the caller.  Also, why can't I have a key that is scoped at a different 
level depending on the calling context.

Darren