On Fri, Jul 25, 2014 at 2:35 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> > On Jul 24, 2014, at 5:43 PM, Yuriy Taraday <yorik....@gmail.com> wrote: > > > > > On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann <d...@doughellmann.com> > wrote: > >> >> On Jul 24, 2014, at 3:08 PM, Yuriy Taraday <yorik....@gmail.com> wrote: >> >> >> >> >> On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann <d...@doughellmann.com> >> wrote: >> >>> >>> On Jul 24, 2014, at 1:58 PM, Yuriy Taraday <yorik....@gmail.com> wrote: >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann <d...@doughellmann.com> >>> wrote: >>> >>>> >>>> On Jul 23, 2014, at 11:10 PM, Baohua Yang <yangbao...@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev