openstack team mailing list archive

[Dan Prince <dprince@xxxxxxxxxx>]

----- Original Message -----
> From: "Sean Dague" <sdague@xxxxxxxxxxxxxxxxxx>
> To: openstack@xxxxxxxxxxxxxxxxxxx
> 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: sdague@xxxxxxxxxxxxxxxxxx
> alt-email: sldague@xxxxxxxxxx
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>