Open Stack

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.

-- 

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