On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann <[email protected]> wrote:
> > On Jul 24, 2014, at 1:58 PM, Yuriy Taraday <[email protected]> wrote: > > > > > On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann <[email protected]> > wrote: > >> >> On Jul 23, 2014, at 11:10 PM, Baohua Yang <[email protected]> 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.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
