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