Open Stack

On Jul 25, 2014, at 1:19 AM, Yuriy Taraday <yorik.sar at gmail.com> wrote:

> 
> 
> 
> On Fri, Jul 25, 2014 at 2:35 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> On Jul 24, 2014, at 5:43 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>> On Jul 24, 2014, at 3:08 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>>> 
>>> On Jul 24, 2014, at 1:58 PM, Yuriy Taraday <yorik.sar at gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>>>> 
>>>> On Jul 23, 2014, at 11:10 PM, Baohua Yang <yangbaohua at gmail.com> wrote:
>>>> 
>>>>> Hi, all
>>>>>      The current oslo.cfg module provides an easy way to load name known options/groups from he configuration files.
>>>>>       I am wondering if there's a possible solution to dynamically load them?
>>>>> 
>>>>>       For example, I do not know the group names (section name in the configuration file), but we read the configuration file and detect the definitions inside it.
>>>>> 
>>>>> #Configuration file:
>>>>> [group1]
>>>>> key1 = value1
>>>>> key2 = value2
>>>>> 
>>>>>        Then I want to automatically load the group1. key1 and group2. key2, without knowing the name of group1 first.
>>>> 
>>>> If you don’t know the group name, how would you know where to look in the parsed configuration for the resulting options?
>>>> 
>>>> I can imagine something like this:
>>>> 1. iterate over undefined groups in config;
>>>> 2. select groups of interest (e.g. by prefix or some regular expression);
>>>> 3. register options in them;
>>>> 4. use those options.
>>>> 
>>>> Registered group can be passed to a plugin/library that would register its options in it.
>>> 
>>> If the options are related to the plugin, could the plugin just register them before it tries to use them?
>>> 
>>> Plugin would have to register its options under a fixed group. But what if we want a number of plugin instances? 
>> 
>> Presumably something would know a name associated with each instance and could pass it to the plugin to use when registering its options.
>> 
>>>  
>>> 
>>> I guess it’s not clear what problem you’re actually trying to solve by proposing this change to the way the config files are parsed. That doesn’t mean your idea is wrong, just that I can’t evaluate it or point out another solution. So what is it that you’re trying to do that has led to this suggestion?
>>> 
>>> I don't exactly know what the original author's intention is but I don't generally like the fact that all libraries and plugins wanting to use config have to influence global CONF instance.
>> 
>> That is a common misconception. The use of a global configuration option is an application developer choice. The config library does not require it. Some of the other modules in the oslo incubator expect a global config object because they started life in applications with that pattern, but as we move them to libraries we are updating the APIs to take a ConfigObj as argument (see oslo.messaging and oslo.db for examples).
>> 
>> What I mean is that instead of passing ConfigObj and a section name in arguments for some plugin/lib it would be cleaner to receive an object that represents one section of config, not the whole config at once.
> 
> The new ConfigFilter class lets you do something like what you want [1]. The options are visible only in the filtered view created by the plugin, so the application can’t see them. That provides better data separation, and prevents the options used by the plugin or library from becoming part of its API.
> 
> Doug
> 
> [1] http://docs.openstack.org/developer/oslo.config/cfgfilter.html
> 
> Yes, it looks like it. Didn't know about that, thanks!
> I wonder who should wrap CONF object into ConfigFilter - core or plugin.

If the plugin wraps the object then the plugin can register new options that other parts of the application can’t see (because their values are only known to the wrapper, which the application doesn’t have).

Doug

> 
> -- 
> 
> Kind regards, Yuriy.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/65cd28bf/attachment.html>