<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/18/2016 12:17 PM, Michael
Krotscheck wrote:<br>
</div>
<blockquote
cite="mid:CABM65auWVWGd9SH+ge-kJeMfhhMHucPC72m+w2+eTthWx8zG6Q@mail.gmail.com"
type="cite">
<div dir="ltr">Clarifying:<br>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Feb 18, 2016 at 2:32 AM Sean Dague
<<a moz-do-not-send="true" href="mailto:sean@dague.net">sean@dague.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, to
make sure we all ended up on the same page at the end of
this<br>
discussion, this is what I think I heard.<br>
<br>
1) oslo.config is about to release with a feature that
will make adding<br>
config to paste.ini not needed (i.e.<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/265415/"
rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265415/</a>
is no longer needed).<br>
</blockquote>
<div><br>
</div>
<div>I will need help to do this. More below.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">2)
ideally the cors middleware will have sane defaults for
that set of<br>
headers in oslo.config.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">3)
projects should be able to apply new defaults for these
options in<br>
their codebase through a default override process (that is
now nicely<br>
documented somewhere... url?)</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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: <br>
<br>
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. <br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CABM65auWVWGd9SH+ge-kJeMfhhMHucPC72m+w2+eTthWx8zG6Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>The big question I now have is: What do we do with
respect to the mitaka freeze?</div>
<div>
<div><br>
</div>
<div>Option 1: Implement as is, keep things consistent,
fix them in Newton.</div>
<div><br>
</div>
<div>Option 2: Try to fix it in Mitaka.<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<div>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.</div>
<div><br>
</div>
<div>Who's willing to help?</div>
<div><br>
</div>
<div>Michael</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>