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