Open Stack

Clarifying:

On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/26d1c206/attachment.html>