[openstack-dev] [oslo] upgrade implications of lots of content in paste.ini
morgan.fainberg at gmail.com
Thu Feb 18 19:00:28 UTC 2016
CORS shouldn't need catalog integration ever. CORS is a layer above
anything in the service catalog and doesn't provide extra security except
current domain; something that can be worked around in many ways including
reject the request.
I don't see service catalog integration as a blocker for CORS.
On Thu, Feb 18, 2016 at 10:29 AM, John Garbutt <john at johngarbutt.com> wrote:
> 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
> >> 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
> >> 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
> >> their codebase through a default override process (that is now
> >> 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:
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev