openstack team mailing list archive

["Mark Washenberger" <mark.washenberger@xxxxxxxxxxxxx>]

"Sean Dague" <sdague@xxxxxxxxxxxxxxxxxx> said:

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

Logging sounds like a great way to communicate to deployers and operators,
but really doesn't seem the best way to communicate with developers. So
my question is, are we using this mechanism to deprecate things the deployers
can control? Or is it things that developers need to deal with? If its the
latter (which it seems), I'd prefer that we just use our various developer
coordinating communication channels, such as the team meetings, IRC, mailing
list, etc.

One relationship where it does make sense to me to do this python
warnings-style deprecation is library-publisher to library-client. So maybe
this mechanism makes more sense as-is in openstack common for deprecating
functions and classes from the common library. (But internally for a project
like Nova. . I'm not sure I get it.)