← Back to team overview

openstack team mailing list archive

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