[openstack-dev] [openstack][nova] Streamlining of config options in nova
rpodolyaka at mirantis.com
Thu Jul 23 16:23:43 UTC 2015
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db 
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per backend,
per driver, etc), rather than per Python module to reduce the number
of possible circular imports when using import_opt() helper.
On Thu, Jul 23, 2015 at 6:39 PM, Kevin L. Mitchell
<kevin.mitchell at rackspace.com> wrote:
> 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
>> 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
>> 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
> 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
> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev