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

Adam Young ayoung at redhat.com
Thu Feb 18 18:21:37 UTC 2016

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
>     adding
>     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 of
>     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 in
>     their codebase through a default override process (that is now nicely
>     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.
So, I think we need to treat CORS as experimental for the time being 
anyway.  When I last looked in to it, we really needed Service catalog 
integration to avoid being too permissive:

As I understand it, the CORS middleware as it is currently written does 
not limit what other application would be able to read the data back 
from a POST operation.

Any Application can make a subset of calls to Keystone, but we don't 
want any but a "blessed" application able to read the tokens.  We have a 
hard coded check for this to support Federation already. This pattern 
needs to extend to any Application trusted to get and read a Keystone token.

> 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.
> Option 2: Try to fix it in Mitaka.
> This requires patches against Heat, Nova, Aodh, Ceilometer, Keystone, 
> Mistral, Searchlight, Designate, Manila, Barbican, Congress, Neutron, 
> Cinder, Magnum, Sahara, Trove, Murano, Glance, Cue, Kite, Solum, 
> Ironic. These patches have to land after the next oslo release has 
> made it into global requirements, and requires the +2's of the 
> appropriate cores.
> I will need help, both to write and land those patches. We're super 
> tight against feature freeze, and I'm currently overcommitted with the 
> Ironic and Horizon midcycles (this week and next). I also have an 
> infant at home, with no daycare, so I cannot work long hours to make 
> this happen.
> I feel that I can commit to landing 5 of the 22 required patches. If I 
> cannot get support for the remaining 17, we risk having an 
> inconsistent implementation, in which case Option 1 is preferred.
> Who's willing to help?
> Michael
> __________________________________________________________________________
> 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/20160218/cba10ee9/attachment.html>

More information about the OpenStack-dev mailing list