openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #12755
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?
Cheers,
Mark.
References