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
