cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: Configuration variable changes...
Date Wed, 11 Sep 2013 16:40:43 GMT
> 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.

A similar usage is already on the ConfigDepot interface.  

ConfigKey<?> get(String key);

I can probably add a method with the exact same signature but really all it does will be check
the type and cast.

> 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.

That's a good question.  I had the same question when I looked at the original implementation
of scoped variables.  The scope is defined in both the key and when getting value but they're
always the same so essentially it's defined in the key and not the get value.  I agree with
your assessment that it's much more flexible to have the scope defined when getting the value,
but since I'm mostly refactoring here, I didn't want to get too far away from the original
intent of the scope code so I left the scope definition in the key for now.  Maybe the original
implementer can take a look to see if that flexibility makes sense for their requirements.

I can see for example that at least the original implementation does not really have a true
scope implementation where it checks cluster, then pod, then zone, then global.  It only checked
the scope that was defined in the key.  It would have been much better if the scope in the
key defined the depth of the scope and the scope in get value defined where to start search
for the override within that depth.

View raw message