Thanks for bringing this to wider attention, definitely deserves discussion.
I'm all for getting rid of spurious log messages, but I agree that this would likely break out-of-tree extensions, meaning that it may not be a good trade-off. There actually a related blueprint that indirectly might have a bearing on this, as well: https://blueprints.launchpad.net/quantum/+spec/load-plugin-supported-extensions Just as this blueprint points out that there's no point in loading extensions that are not supported by the currently selected plugin, one might argue that there is no point in warning the user about the existence of a non-extension file in the extensions directory if the plugin was able to find all of the extensions that it supports. Instead, one could print an warning only if the plugin claimed support for an extension alias that was not found. If the goal is simply to avoid a logged warning message during normal operation, this would be sufficient. Dan On Mon, Nov 5, 2012 at 10:00 AM, Mark McClain <[email protected]>wrote: > I wanted to make sure that all of the cores saw this proposed change: > > https://review.openstack.org/#/c/15425/ > > Should we have a deprecation period during Grizzly to allow out of tree > extensions and plugins to catch up with the change? > > mark > > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
