----- Original Message ----- > From: "Sean Dague" <[email protected]> > To: [email protected] > Sent: Wednesday, June 13, 2012 3:07:54 PM > Subject: Re: [Openstack] The right way to deprecate things in nova? > > On 06/13/2012 01:35 PM, Mark Washenberger wrote: > <snip> > >> 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. > > So for deprecating some piece of Operator facing interface, I agree > we > can do that without anything as heavy as a decorators. So how about > this > instead, have a user_deprecate(msg="") function. > > It's a wrapper on the LOG function, with some standard formatting > that > makes sure all the user deprecated features have an easy grepable > pattern in the log. Also add the fatal functionality, so that people > can > sniff test their system before upgrading to N+1 that they aren't > using > deprecated configs. > > It wouldn't be a decorator, just a function that can be placed inside > code.
I like this approach the best. No decorator... just a simple function in utils that log the deprecation warning in a sane manner. > > -Sean > > -- > Sean Dague > IBM Linux Technology Center > email: [email protected] > alt-email: [email protected] > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
