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

Sean Dague sdague at linux.vnet.ibm.com
Wed Jun 13 14:12:10 UTC 2012


On 06/12/2012 05:53 PM, Dan Prince wrote:
<snip>
>> 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.

So up until this point OpenStack has been a pretty much a rip and 
replace model. You want to go from Diablo to Essex, shut everything 
down, upgrade, bring back up. When I went to change this parameter 
originally, the review comments included just ripping out the old 
function, and not deprecating it.

But I think we are moving into a phase where real OpenStack deployments 
are going to have N and N+1 release componets talking to each other. so 
it's probably worth getting in the habbit of having a standard way to 
deprecate out over a release. LOG.warning messages scattered about, 
which may or may not be consistent, that someone might or might not 
remember to remove later, with or without their associated function, 
seems kind of error prone.

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

Grepping for log files assumes the deprecation messages all look the 
same. It also is a much more active process that people need to think 
about having to do, not something that can be just flagged in jenkins.

	-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