Open Stack

On 2/26/2013 10:12 AM, Huang Zhiteng wrote:
> In a recent Nova patch review
> (https://review.openstack.org/#/c/18718/2), Sean Dague asked about the
> deprecation strategy of configuration options since the patch removes
> two config options as they are no longer applicable after the change.
> I thought documenting the change (removal of old config options) and
> its rationale would be enough but Sean required a more sensible way to
> take care of config option change.
>
> One thing I'm thinking about strategy is keeping the deprecated
> options for one more release, and changing default value of these
> config options to None (but since they are no longer used, it doesn't
> matter what value they get).  What's more, in the place where these
> config options were used, log a deprecation warning.
>
> I'd like to hear opinions, especially sharing similar experiences
> about how to handle such cases from community.
>
I agree with Sean. It is very common to deprecate a no-longer-used 
configuration (or API) and remove it at a later release.
But I think where we are most falling short is on documentation. We 
should assume that downstream users have scripts, recipes, whatever that
are deploying OpenStack (and setting config options), and some 
acceptance test. Any change that we know will cause a reasonable deploy 
or test to fail needs to be documented in the
release notes. Perhaps the easiest way to do this is for developers 
making changes to update 
https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly
in real time. This is better than trying to remember them all at the 
end, and also gives users an opportunity to comment if they think an 
incompatible change is ill-advised.

  -David