Open Stack

Excerpts from Michael Krotscheck's message of 2016-02-17 17:26:57 +0000:
> We (that is, the cores, contributors, and consumers that I've been
> collaborating with over the past year on this) came to the consensus that
> leaving the cors middleware as generic & configurable as possible was
> preferable, and that an openstack-specific version that automatically
> initializes itself from keystone's service catalog and trusted dashboards
> might be a next step. I'm sure the oslo core team can chime in, but the
> arguments that I recall were:
> 
> 1- Maintaining a list of headers in a repository separate from projects
> that use them is undesirable and likely to bitrot.
> 2- Oslo's backwards-compatibility policy means that new and/or modified
> headers could only be added, not removed. This would result in a long list
> of no-longer used headers (https://tools.ietf.org/html/rfc6648 was
> mentioned).
> 3- We could not guarantee that downstream consumers of the CORS middleware
> don't already exist, and they should not be subject to having
> suddenly-approved headers.
> 
> We'd like to move forward with this approach at this time, to ensure that
> CORS is consistently enabled in Mitaka before the freeze. I'd be happy to
> work with you on alternative approaches moving forwards; for example, I
> think teaching oslo's genconfig to permit project-specific default
> overrides would solve this problem in a way that would make both of us, and
> other users of genconfig, very happy.

The next release of oslo.config will have this.
https://review.openstack.org/#/c/278604/

Doug

> 
> Michael
> 
> On Wed, Feb 17, 2016 at 5:08 AM Sean Dague <sean at dague.net> wrote:
> 
> > A set of CORS patches came out recently that add a ton of content to
> > paste.ini for every project (much of it the same between projects) -
> > https://review.openstack.org/#/c/265415/1
> >
> > paste.ini is in a really weird space because it's config, ops can change
> > it, so large amounts of complicated things in there which may change in
> > future releases is really problematic. Deprecating content out of there
> > turns into a giant challenge because of this. As does changes to code
> > which make any assumption what so ever about other content in that file.
> >
> > Why weren't these options included as sane defaults in the base cors
> > middleware?
> >
> >         -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >