Open Stack

On Thu, Feb 18, 2016 at 9:58 AM, Sean Dague <sean at 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 <sean at dague.net
> > <mailto:sean at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/8530f508/attachment.html>