<div dir="ltr"><div><div>Adam,<br><br></div>CORS shouldn't need catalog integration ever. CORS is a layer above anything in the service catalog and doesn't provide extra security except signalling to the javascript vm it can access resources outside of it's current domain; something that can be worked around in many ways including using a non-javascript http client. The underlying application can still reject the request.<br><br></div><div>I don't see service catalog integration as a blocker for CORS.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 10:29 AM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 18 February 2016 at 17:58, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
> 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">sean@dague.net</a><br>
>> <mailto:<a href="mailto:sean@dague.net">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>
> 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>
<br>
</div></div>+1 on the upgrade impact being a blocker.<br>
Certainly for all folks meeting these:<br>
<a href="https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements" rel="noreferrer" target="_blank">https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements</a><br>
<br>
This will require lots of folks to pitch in a help, and bend the<br>
process a touch.<br>
But that seems way more reasonable than dragging our users through<br>
that headache.<br>
<br>
Thanks,<br>
John<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>