Open Stack

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>