← Back to team overview

openstack team mailing list archive

Re: the right way to deprecate a config option?


Hi Sean,

On Fri, 2012-06-01 at 16:15 -0400, Sean Dague wrote:
> I'm reworking the virt driver loading so that it's using importutils 
> (and thus looking more like the other driver interfaces), which means 
> eventually connection_type parameter in nova.conf goes away, and 
> computer_driver is used directly (the support is already there, but it's 
> not currently used by default).
> Is there a standard mechanism for deprecating a conf option like this? 
> Right now I'm just triggering a LOG.error() with a deprecation message, 
> but it seems like there should be something more standard for that, 
> especially as we get into a deprecate in N, remove in N+1. I'm assuming 
> this is a deprecation in Folsom (where the docs are changed to the new 
> method), then remove the backwards compat in G.

FWIW, deprecating in Folsom, adding an error log about the deprecation
and removing it in G sounds like the right thing to me.

Maybe a utils.deprecated() utility method for logging the message would
help make sure we don't loose track of stuff that should be removed in
the next release?