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. -- Kind regards, Yuriy.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev