| 2012-07-17 18:34:41 |
Andrew Bogott |
description |
Right now we have an optional notifier driver, list_notifier, which handles n notifiers. It works perfectly well for n = 0 or 1, so there's no real reason to not always use the list notifier. And, going further, there's no reason to consider the list_notifier to be a driver at all; the list behavior should be promoted into the notifier api so that the notifier api always handles n drivers rather than 0 or 1.
The problem that this solves:
There's code in the pluginmanager that switches CONF.notification_driver to the list_notifier driver and then adds the previous CONF.notification_driver to the list. This works, but fiddling with config opts in code is problematic in various ways (among other things, it confounds the tests which expect config values to only be set at startup or via the testing framework.)
Problems this might cause:
Thanks to the existing behavior of StrMultiOpt, existing installs that set CONF.list_notifier once, e.g.
$ notification_driver = foozle <- will still work the same
Will still work as before. If, however, someone has a buggy nova.conf that sets CONF.list_notifier twice
$ notification_driver = foozle
$ notification_driver = oopsIMeantFazzle
The behavior will change, as previously only the second driver was used, but in the StrMultiOpt scenario both drivers will be used.
This could be avoided by instituting a new CONF.notification_drivers flag and leaving in a special-case handler if CONF.notification_driver is set instead. No idea if that is necessary though. |
Right now we have an optional notifier driver, list_notifier, which handles n notifiers. It works perfectly well for n = 0 or 1, so there's no real reason to not always use the list notifier. And, going further, there's no reason to consider the list_notifier to be a driver at all; the list behavior should be promoted into the notifier api so that the notifier api always handles n drivers rather than 0 or 1.
The problem that this solves:
There's code in the pluginmanager that switches CONF.notification_driver to the list_notifier driver and then adds the previous CONF.notification_driver to the list. This works, but fiddling with config opts in code is problematic in various ways (among other things, it confounds the tests which expect config values to only be set at startup or via the testing framework.)
Problems this might cause:
Thanks to the existing behavior of StrMultiOpt, existing installs that set CONF.list_notifier once, e.g.
$ notification_driver = foozle
...will still work as before. If, however, someone has a buggy nova.conf that sets CONF.list_notifier twice
$ notification_driver = foozle
$ notification_driver = oopsIMeantFazzle
...the behavior will change, as previously only the second driver was used, but in the StrMultiOpt scenario both drivers will be used.
This could be avoided by instituting a new CONF.notification_drivers flag and leaving in a special-case handler if CONF.notification_driver is set instead. No idea if that is necessary though. |
|
