On Thu, Feb 18, 2016 at 9:58 AM, Sean Dague <s...@dague.net> wrote: > On 02/18/2016 12:17 PM, Michael Krotscheck wrote: > > Clarifying: > > > > On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <s...@dague.net > > <mailto:s...@dague.net>> wrote: > > > > Ok, to make sure we all ended up on the same page at the end of this > > discussion, this is what I think I heard. > > > > 1) oslo.config is about to release with a feature that will make > adding > > config to paste.ini not needed (i.e. > > https://review.openstack.org/#/c/265415/ is no longer needed). > > > > > > I will need help to do this. More below. > > > > > > 2) ideally the cors middleware will have sane defaults for that set > of > > headers in oslo.config. > > > > > > I'd like to make sure we agree on what "Sane defaults" means here. By > > design, the CORS middleware is generic, and only explicitly includes the > > headers prescribed in the w3c spec. It should not include any > > additional headers, for reasons of downstream non-openstack consumers. > > > > > > 3) projects should be able to apply new defaults for these options in > > their codebase through a default override process (that is now nicely > > documented somewhere... url?) > > > > > > New sample defaults for the generated configuration files, they should > > not live anywhere else. The CORS middleware should, if we go this path, > > be little more than a true-to-spec implementation, with config files > > that extend it for the appropriate API. > > > > The big question I now have is: What do we do with respect to the mitaka > > freeze? > > > > Option 1: Implement as is, keep things consistent, fix them in Newton. > > The problem with Option 1 is that it's not fixable in Newton. It > requires fixing for the next 3 releases as you have to deprecate out > bits in paste.ini, make middleware warn for removal first soft, then > hard, explain the config migration. Once this lands in the wild the > unwind is very long and involved. > > Which is why I -1ed the patch. Because the fix in newton isn't a revert. > > -Sean > > -- > Sean Dague > http://dague.net > > Updates to defaults in paste-ini will cause pain regardless of 1, 2, or 3 cycles out and will likely break deployments / make operator lives miserable. Putting config values in paste-ini (except in the case of swift when using middleware that relies on oslo.config, and it wont be in the paste-ini by default) is going to cause pain and is generally a bad idea.
I am against "option 1". This could be a case where we classify it as a release blocking bug for Mitaka final (is that reasonable to have m3 with the current scenario and final to be fixed?), which opens the timeline a bit rather than hard against feature-freeze.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
