<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 9:58 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/18/2016 12:17 PM, Michael Krotscheck wrote:<br>
> Clarifying:<br>
><br>
> On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
</span><span>> <mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>> wrote:<br>
><br>
>     Ok, to make sure we all ended up on the same page at the end of this<br>
>     discussion, this is what I think I heard.<br>
><br>
>     1) oslo.config is about to release with a feature that will make adding<br>
>     config to paste.ini not needed (i.e.<br>
>     <a href="https://review.openstack.org/#/c/265415/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265415/</a> is no longer needed).<br>
><br>
><br>
> I will need help to do this. More below.<br>
><br>
><br>
>     2) ideally the cors middleware will have sane defaults for that set of<br>
>     headers in oslo.config.<br>
><br>
><br>
> I'd like to make sure we agree on what "Sane defaults" means here. By<br>
> design, the CORS middleware is generic, and only explicitly includes the<br>
> headers prescribed in the w3c spec.  It should not include any<br>
> additional headers, for reasons of downstream non-openstack consumers.<br>
><br>
><br>
>     3) projects should be able to apply new defaults for these options in<br>
>     their codebase through a default override process (that is now nicely<br>
>     documented somewhere... url?)<br>
><br>
><br>
> New sample defaults for the generated configuration files, they should<br>
> not live anywhere else. The CORS middleware should, if we go this path,<br>
> be little more than a true-to-spec implementation, with config files<br>
> that extend it for the appropriate API.<br>
><br>
> The big question I now have is: What do we do with respect to the mitaka<br>
> freeze?<br>
><br>
> Option 1: Implement as is, keep things consistent, fix them in Newton.<br>
<br>
</span>The problem with Option 1 is that it's not fixable in Newton. It<br>
requires fixing for the next 3 releases as you have to deprecate out<br>
bits in paste.ini, make middleware warn for removal first soft, then<br>
hard, explain the config migration. Once this lands in the wild the<br>
unwind is very long and involved.<br>
<br>
Which is why I -1ed the patch. Because the fix in newton isn't a revert.<br>
<span><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span></blockquote><div><br></div><div>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.<br><br></div><div>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. <br></div></div><br></div></div>