[Openstack] The right way to deprecate things in nova?

Sean Dague sdague at linux.vnet.ibm.com
Tue Jun 12 19:50:45 UTC 2012


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 at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com





More information about the Openstack mailing list