On Tue, 2014-08-26 at 10:00 -0400, Doug Hellmann wrote: > On Aug 26, 2014, at 6:30 AM, Mark McLoughlin <mar...@redhat.com> wrote: > > > On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote: > >> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen > >> <devananda....@gmail.com> wrote: > >> > >>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann <d...@doughellmann.com> > >>> wrote: > >>>> > >>>> That’s right. The preferred approach is to put the register_opt() in > >>>> *runtime* code somewhere before the option will be used. That might be in > >>>> the constructor for a class that uses an option, for example, as > >>>> described > >>>> in > >>>> http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options > >>>> > >>>> Doug > >>> > >>> Interesting. > >>> > >>> I've been following the prevailing example in Nova, which is to > >>> register opts at the top of a module, immediately after defining them. > >>> Is there a situation in which one approach is better than the other? > >> > >> The approach used in Nova is the “old” way of doing it. It works, but > >> assumes that all of the application code is modifying a global > >> configuration object. The runtime approach allows you to pass a > >> configuration object to a library, which makes it easier to mock the > >> configuration for testing and avoids having the configuration options > >> bleed into the public API of the library. We’ve started using the > >> runtime approach in new Oslo libraries that have configuration > >> options, but changing the implementation in existing application code > >> isn’t strictly necessary. > > > > I've been meaning to dig up some of the old threads and reviews to > > document how we got here. > > > > But briefly: > > > > * this global CONF variable originates from the gflags FLAGS variable > > in Nova before oslo.config > > > > * I was initially determined to get rid of any global variable use > > and did a lot of work to allow glance use oslo.config without a > > global variable > > > > * one example detail of this work - when you use paste.deploy to > > load an app, you have no ability to pass a config object > > through paste.deploy to the app. I wrote a little helper that > > used a thread-local variable to mimic this pass-through. > > > > * with glance done, I moved on to making keystone use oslo.config and > > initially didn't use the global variable. Then I ran into a veto > > from termie who felt very strongly that a global variable should be > > used. > > > > * in the end, I bought the argument that the use of a global variable > > was pretty deeply ingrained (especially in Nova) and that we should > > aim for consistent coding patterns across projects (i.e. Oslo > > shouldn't be just about shared code, but also shared patterns). The > > only realistic "standard pattern" we could hope for was the use of > > the global variable. > > > > * with that agreed, we reverted glance back to using a global > > variable and all projects followed suit > > > > * the case of libraries is different IMO - we'd be foolish to design > > APIs which lock us into using the global object > > > > So ... I wouldn't quite agree that this is "the new way" vs "the old > > way", but I think it would be reasonable to re-open the discussion about > > using the global object in our applications. Perhaps, at least, we could > > reduce our dependence on it. > > The aspect I was calling “old” was the “register options at import > time” pattern, not the use of a global. Whether we use a global or > not, registering options at runtime in a code path that will be using > them is better than relying on import ordering to ensure options are > registered before they are used.
I don't think I've seen code (except for obscure cases) which uses the CONF global directly (as opposed to being passed CONF as a parameter) but doesn't register the options at import time. Mark. _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev