Open Stack

Daniel P. Berrange wrote:
> On Tue, Nov 11, 2014 at 10:24:41AM +0000, Dave Walker wrote:
>> Hi,
>>
>> Looking at a stable/juno cinder proposed change[0], I came across one
>> that introduces a new config option.
>>
>> The default is a noop change for the behaviour, so no bad surprises on upgrade.
>>
>> These sort of changes feel like they are outside the 'no config
>> changes' rule, but we have not really discussed this.
>>
>> What do others think?
> 
> I don't think "no config changes" is a completely black & white rule.
> The most important part of it is that you don't change the semantics
> or default values of any existing config options in stable, because
> that would cause a change in behaviour for existing deployments who
> upgrade.
> 
> If backporting a bug fix involves adding a new config parameter I
> think that's broadly acceptable, provided the config option does
> not result in a change in behaviour upon upgrade that violates the
> stable tree requirements.

New config options may not change behavior (if default value preserves
behavior), they still make documentation more incomplete (doc, books,
and/or blogposts about Juno won't mention that option).

That's why any change requiring a config option to be added needs a
stable rules exception to be granted. Stable-maint-core needs to weigh
the benefit of the change against the drawbacks, and decide if it's
worth it.

In the past we accepted a few of those exception requests in case of
significant security issues. This one is a bit borderline (security
issue, but there are many other ways to achieve the same result). I'd
lean towards accepting it, though.

-- 
Thierry Carrez (ttx)