[openstack-dev] oslo.config improvements

Shaun McCance shaunm at gnome.org
Fri Feb 7 16:35:23 UTC 2014


I've been working on the code that generates our configuration docs. A
couple week ago, I rewrote most of it to address some major problems,
most notably its inability to distinguish same-named options in
different groups.

I've tried to reuse bits from the oslo-incubator code to generate sample
config files, but it's been tricky. Failing that, I've tried to write
the docs generator in a way where its code could be moved somewhere and
reused by multiple projects.

The way the config file generator in oslo-incubator works right now has
some major problems, which I'd like to address:

1) Because of the way it iterates over modules, then over all options,
it's considerably slower than it should be. The config file generator
groups by defining module, so it needs that info. The config docs
gnerator doesn't do anything with the defining module right now, but I
wouldn't rule out the possibility in the future.

2) It locates options based on them being defined at the top level of a
module (not in function or packed into some object), but it gets info by
looking at cfg.CONF, which require registration. This fails if an option
is defined by only registered when some function is called. This happens
right now with the ip_lib_force_root option in Neutron. Both the config
file generator and config docs generator currently crash on Neutron
because of this.

3) It's completely incapable of finding options that aren't defined or
registered until some function is called or some object is instantiated.
I don't have a general solution to this, although I do have special-case
code that detects projects that use oslo.messaging and ensures those
options get registered.

To address these issues, I'd like to get oslo.config to know about the
defining module for each option. It can get that using something like
this in Opt.__init__:

for frame in inspect.stack():
    mod = inspect.getmodule(frame[0])
    if mod == sys.modules[__name__]:
        continue
    self.module = mod.__name__
        break

We'd also have to modify __eq__ and __ne__, because it's valid for an
option to be defined in two different modules as long as all its
parameters are the same. Checking vars() equality would trip up on the
module. (There's the further issue that the defining module is
non-deterministic in those cases.)

Then I'd like to get both the config file generator and the config docs
generator using something like the OptionsCache class I wrote for the
config docs generator:

http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/common.py#n88

This could be simpler and faster and avoid the crash mentioned above
with the module info attached to each option.

Is any part of this feasible? Has anybody else worked on resolving these
types of issues with the config file generator?

--
Shaun





More information about the OpenStack-dev mailing list