Excerpts from Sean Dague's message of 2016-02-18 12:55:02 -0500: > On 02/18/2016 12:22 PM, Michael Krotscheck wrote: > > On Thu, Feb 18, 2016 at 9:07 AM Doug Hellmann <d...@doughellmann.com > > <mailto:d...@doughellmann.com>> wrote: > > > > > > If the deployer is only ever supposed to set the value to the default, > > why do we let them change it at all? Why isn't this just something the > > app sets? > > > > > > There was a specific request from the ironic team to not have headers be > > prescribed. If, for instance, ironic is deployed with an auth plugin > > that is not keystone, different allowed headers would be required. > > Here is the future we're going to have. > > Whatever the middleware does with no operator intervention will be how > the world will work, and how you will need to assume the world will work > going forward. > > Right now, it appears that the default in the middleware is do nothing. > That means CORS won't be in a functional state on services by default. > However, I thought the point of the effort was that all the APIs in the > wild would be CORS enabled. > > I'm not hugely sympathetic to defaulting to not having the Keystone > headers specified in the non keystone case. I get there are non keystone > cases, but keystone is defcore. Making the keystone case worse for the > non keystone case seems like fundamentally the wrong tradeoff. > > -Sean >
I agree. We should make this thing work for our needs first, and allow flexibility on top of that. But the default should be made useful. Doug __________________________________________________________________________ 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
