Open Stack

On Thu, 2015-07-23 at 17:55 +0300, mhorban wrote:
> During development process in nova I faced with an issue related with config
> options. Now we have lists of config options and registering options mixed
> with source code in regular files.
>  From one side it can be convenient: to have module-encapsulated config
> options. But problems appear when we need to use some config option in
> different modules/packages.
> 
> If some option is registered in module X and module X imports module Y for
> some reasons...
> and in one day we need to import this option in module Y we will get 
> exception
> NoSuchOptError on import_opt in module Y.
> Because of circular dependency.
> To resolve it we can move registering of this option in Y module(in the
> inappropriate place) or use other tricks.

Isn't this use case what the import_opt() method of CONF is for?  The
description given in the docstring is:

        Import a module and check that a given option is registered.
        
        This is intended for use with global configuration objects
        like cfg.CONF where modules commonly register options with
        CONF at module load time. If one module requires an option
        defined by another module it can use this method to explicitly
        declare the dependency.

It's used all over the place in nova for this purpose, as far as I can
see.

> I offer to create file options.py in each package and move all package's
> config options and registration code there.
> Such approach allows us to import any option in any place of nova without
> problems.

The problem with this reorganization is that it moves the options from
the place where they're primarily intended to be used.  This could make
it harder to maintain, such as ensuring the help text is updated when
the code is.  If nova were a smaller code base, I think it would make
sense to reorganize in this fashion, but given how large nova actually
is…
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace