<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>The conversations around alternative wsgi containers (uwsgi, gunicorn, etc) still would be tied to apache or nginx. While it is possible to deploy without the webservers in some cases, jt would not be recommended nor do I see that being tested in gate. We want to leverage the auth support of the webserver. While uWSGI has interesting features, it wouldnt really replace nginx or apache. It is just an alternative deployment strategy that makes managing the keystone (or any OpenStack service) processes independent of the web server. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I do not expect any of these choices to have a performance impact. It will ease some operational concerns. There is no reason uwsgi or gunicorn wont work today (I have run keystone with both in a devstack locally). The documentation and communicating the reasons to pick one or the other is all that is needed. From a gate perspective configuration and restarts of the web server could be made easier in devstack with uWSGI. It would not prevent use of mod_wsgi. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">--Morgan</div><div id="AppleMailSignature"><br>Sent via mobile</div><div><br>On Sep 18, 2015, at 09:53, Yee, Guang <<a href="mailto:guang.yee@hpe.com">guang.yee@hpe.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">I am with Adam, I kinda doubt Apache cause performance issues for Keystone, especially since all we have are just simple REST APIs. For other services with specific needs, like large file streaming, there may be some arguments to pick one
over the other. We haven’t had the need to use Apache for dynamic routing or proxying at deployment. I am sure there are better tools out there that can do the job.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Making Keystone web service independent is a fine goal. However, since Keystone is moving away from being an identity provider, federation and external auth will play a major part going forward. Some of them are depended on the Apache at
the moment. We may have to refactor Keystone to isolate the authentication service from the rest, then figure out how to gate it with Apache. I don’t think that’s trivial work though.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At this point, I don’t know what we are really gaining by ripping out Apache, comparing to amount of work to make that happen.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Guang<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Vladimir Kuklin [<a href="mailto:vkuklin@mirantis.com">mailto:vkuklin@mirantis.com</a>]
<br>
<b>Sent:</b> Friday, September 18, 2015 9:09 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [openstack-dev] Apache2 vs uWSGI vs ...<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Folks<o:p></o:p></p>
<p>I just suggested to untie keystone from wsgi and implement uwsgi support. And then let the user decide what he or she wants.
<o:p></o:p></p>
<p>There is a plenty of auth modules for nginx also.<o:p></o:p></p>
<p>Nginx us much better as a proxy server and you know it.<o:p></o:p></p>
<p>Regarding mod wsgi and apache we already saw that it cannot handle simple restart. I think this is not in any way acceptable from operations point if view.
<o:p></o:p></p>
<div>
<p class="MsoNormal">18 сент. 2015 г. 18:59 пользователь "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> написал:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Part of the reason to use Apache though is the diverse set of authentication mechanisms it supports. Operators have the desire to plugin Keystone into their existing authentication systems and Apache tends to be easier to do that then others.<br>
<br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Jim Rollenhagen [<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>]<br>
Sent: Thursday, September 17, 2015 7:04 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] Apache2 vs uWSGI vs ...<br>
<br>
On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:<br>
> In the fuel project, we recently ran into a couple of issues with Apache2 +<br>
> mod_wsgi as we switched Keystone to run . Please see [1] and [2].<br>
><br>
> Looking deep into Apache2 issues specifically around "apache2ctl graceful"<br>
> and module loading/unloading and the hooks used by mod_wsgi [3]. I started<br>
> wondering if Apache2 + mod_wsgi is the "right" solution and if there was<br>
> something else better that people are already using.<br>
><br>
> One data point that keeps coming up is, all the CI jobs use Apache2 +<br>
> mod_wsgi so it must be the best solution....Is it? If not, what is?<br>
<br>
Disclaimer: it's been a while since I've cared about performance with a<br>
web server in front of a Python app.<br>
<br>
IIRC, mod_wsgi was abandoned for a while, but I think it's being worked<br>
on again. In general, I seem to remember it being thought of as a bit<br>
old and crusty, but mostly working.<br>
<br>
At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0]<br>
and saw a significant performance increase. This was a Django app. uwsgi<br>
is fairly straightforward to operate and comes loaded with a myriad of<br>
options[1] to help folks make the most of it. I've played with Ironic<br>
behind uwsgi and it seemed to work fine, though I haven't done any sort<br>
of load testing. I'd encourage folks to give it a shot. :)<br>
<br>
Of course, uwsgi can also be ran behind Apache2, if you'd prefer.<br>
<br>
gunicorn[2] is another good option that may be worth investigating; I<br>
personally don't have any experience with it, but I seem to remember<br>
hearing it has good eventlet support.<br>
<br>
// jim<br>
<br>
[0] <a href="https://uwsgi-docs.readthedocs.org/en/latest/" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/</a><br>
[1] <a href="https://uwsgi-docs.readthedocs.org/en/latest/Options.html" target="_blank">
https://uwsgi-docs.readthedocs.org/en/latest/Options.html</a><br>
[2] <a href="http://gunicorn.org/" target="_blank">http://gunicorn.org/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div></blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>