Open Stack

On 02/26/2013 10:55 AM, David Kranz wrote:
> 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.

Also ++. The part about people deploying OpenStack with scripts/recipes
is critical. Large deployments aren't being done with devstack, and
while devstack is a wonderfully useful developer and testing tool, the
thing that has really lagged behind trunk and packagers is the myriad
Chef and Puppet cookbooks/modules that deploy OpenStack in an automated
fashion. Just removing options from config files *breaks these types of
deployments*, and a warning of deprecation at a minimum is needed.

Best,
-jay