Open Stack

On 27 February 2013 04:12, Huang Zhiteng <winston.d at gmail.com> 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've proposed a session for ODS about continuous deployment - and this
sort of thing is one of the key elements - its essential folk running
automated deployments be able to deploy two adjacent builds gracefully
- because until they have fully transitioned, they can't cleanup
settings the older build depended on. For folk doing major release
upgrades, 'adjacent build' could me 6 months apart. For folk doing CD,
adjacent builds might be a few hours apart.

So, +1 from me on:
 - keep the old option
 - issue a deprecation *warning*
 - drop the option and warning after whatever period we want skewed
deploys to interoperate across (e.g. 1 release).

-Rob

--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services