Open Stack

Hi all,

FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]

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.

Thanks,
Roman

[0] https://github.com/openstack/oslo.db/blob/master/oslo_db/options.py

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
>> 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev