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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
