On 02/18/2016 12:17 PM, Michael Krotscheck wrote:
Clarifying:
On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <s...@dague.net
<mailto:s...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
