[openstack-dev] [oslo] upgrade implications of lots of content in paste.ini
ayoung at redhat.com
Thu Feb 18 18:21:37 UTC 2016
On 02/18/2016 12:17 PM, Michael Krotscheck wrote:
> 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
> 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?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev