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 <s...@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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
