openstack team mailing list archive

[Dan Prince <dprince@xxxxxxxxxx>]

----- Original Message -----
> From: "Sean Dague" <sdague@xxxxxxxxxxxxxxxxxx>
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Sent: Tuesday, June 12, 2012 3:50:45 PM
> Subject: [Openstack] 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)

My take is why keep a 200-300 line set of functions and tests (a small framework) to log messages about code we want to get rid of? As of today we aren't even making use of it and I'm not convinced peppering more decorators all over the place is the best idea. I suppose I have a slight preference for simply logging things here.

>   * 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.

I'm not apposed to this but it seems like grepping log files is also a fine tool. Presumably this would be off by default.

>   * 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

Why not just log it as a simple WARNING and be done with it: https://review.openstack.org/#/c/8411/

> 
> 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
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>