Open Stack

On 18 February 2016 at 17:58, 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.

+1 on the upgrade impact being a blocker.
Certainly for all folks meeting these:
https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements

This will require lots of folks to pitch in a help, and bend the
process a touch.
But that seems way more reasonable than dragging our users through
that headache.

Thanks,
John