Open Stack

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.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/0ac6c885/attachment.html>