Open Stack

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.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com