openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13134
The right way to deprecate things in nova?
I'm in the process of deprecating the old way that we do virt drivers so
that it's fully dynamic -
https://blueprints.launchpad.net/nova/+spec/virt-driver-cleanup
The way the code current exists in master is that a LOG.error is emitted
when the deprecated method is hit. I set it to error level to make sure
it got noticed, as it will require a user configuration change
post-Folsom when the old option is removed. This seems very ad-hoc.
Yesterday I had a conversation with markmc on IRC about this, and he
suggested an approach where we have a config option that makes
deprecation fatal, which could be forced on to ensure cleanliness. This
could be done either as a decorator or as a regular function.
It also turns out there already are some deprecation functions, which
dprince pointed out to me today on IRC, because he was in process of
removing them from nova because they weren't used -
https://review.openstack.org/#/c/8412/.
Here's my current suggested path forward, which I'd like comments on:
* keep the existing nova.utils deprecation functions (don't remove them)
* add the fatal config option, and associated unit tests to make sure
it works correctly. This would be helpful for people to ensure they
weren't depending on deprecated functions towards the end of a release.
* possibly move them to nova.common as they might make for good
openstack-common material down the road
* use this instead of the direct LOG.error in get_connection
This would have the side effect of making the message warning level,
instead of error level, which I think is fine at this point.
-Sean
--
Sean Dague
IBM Linux Technology Center
email: sdague@xxxxxxxxxxxxxxxxxx
alt-email: sldague@xxxxxxxxxx
Follow ups