[openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Michael Krotscheck krotscheck at gmail.com
Wed Feb 17 17:26:57 UTC 2016


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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160217/b3f0174b/attachment.html>


More information about the OpenStack-dev mailing list