[openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

Yuriy Taraday yorik.sar at gmail.com
Thu Jul 24 19:08:55 UTC 2014


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?


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

-- 

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


More information about the OpenStack-dev mailing list