<div dir="ltr">Alexandr,<div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">oauth, shibboleth & openid support are very keystone specific features. Many other openstack projects don't need these modules at all but they may require faster HTTP server (lighthttp/nginx).</span><br></div><div><span style="font-size:13px"><br></span></div><div>For all projects we may use "HTTP server -> uwsgi" model and leave apache for keystone as " HTTP server -> apache -> uwsgi/mod_wsgi". However, I would like to think about whole Openstack ecosystem in general. In that case we'll minimize the number of programs operator should have knowledge.</div><div><br></div><div><br></div><div><span style="font-size:13px"><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div>
<br><div class="gmail_quote">On Fri, Sep 18, 2015 at 4:28 PM, Alexander Makarov <span dir="ltr"><<a href="mailto:amakarov@mirantis.com" target="_blank">amakarov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please consider that we use some apache mods - does<br>
nginx/uwsgi/gunicorn have oauth, shibboleth & openid support?<br>
<div><div class="h5"><br>
On Fri, Sep 18, 2015 at 4:54 PM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>> wrote:<br>
> Folks<br>
><br>
> I think we do not need to switch to nginx-only or consider any kind of war<br>
> between nginx and apache adherents. Everyone should be able to use<br>
> web-server he or she needs without being pinned to the unwanted one. It is<br>
> like Postgres vs MySQL war. Why not support both?<br>
><br>
> May be someone does not need something that apache supports and nginx not<br>
> and needs nginx features which apache does not support. Let's let our users<br>
> decide what they want.<br>
><br>
> And the first step should be simple here - support for uwsgi. It will allow<br>
> for usage of any web-server that can work with uwsgi. It will allow also us<br>
> to check for the support of all apache-like bindings like SPNEGO or whatever<br>
> and provide our users with enough info on making decisions. I did not<br>
> personally test nginx modules for SAML and SPNEGO, but I am pretty confident<br>
> about TLS/SSL parts of nginx.<br>
><br>
> Moreover, nginx will allow you to do things you cannot do with apache, e.g.<br>
> do smart load balancing, which may be crucial for high-loaded installations.<br>
><br>
><br>
> On Fri, Sep 18, 2015 at 4:12 PM, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
>><br>
>> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote:<br>
>><br>
>> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:<br>
>><br>
>> In the fuel project, we recently ran into a couple of issues with Apache2<br>
>> +<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>
>><br>
>> I am not aware of that.  It has been the workhorse of the Python/wsgi<br>
>> world for a while, and we use it heavily.<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>
>><br>
>> Again, switching web servers is as likely to introduce as to solve<br>
>> problems.  If there are performance issues:<br>
>><br>
>> 1.  Idenitfy what causes them<br>
>> 2.  Change configuration settings to deal with them<br>
>> 3.  Fix upstream bugs in the underlying system.<br>
>><br>
>><br>
>> Keystone is not about performance.  Keystone is about security.  The cloud<br>
>> is designed to scale horizontally first.  Before advocating switching to a<br>
>> difference web server, make sure it supports the technologies required.<br>
>><br>
>><br>
>> 1. TLS at the latest level<br>
>> 2. Kerberos/GSSAPI/SPNEGO<br>
>> 3. X509 Client cert validation<br>
>> 4. SAML<br>
>><br>
>> OpenID connect would be a good one to add to the list;  Its been requested<br>
>> for a while.<br>
>><br>
>> If Keystone is having performance issues, it is most likely at the<br>
>> database layer, not the web server.<br>
>><br>
>><br>
>><br>
>> "Programmers waste enormous amounts of time thinking about, or worrying<br>
>> about, the speed of noncritical parts of their programs, and these attempts<br>
>> at efficiency actually have a strong negative impact when debugging and<br>
>> maintenance are considered. We should forget about small efficiencies, say<br>
>> about 97% of the time: premature optimization is the root of all evil. Yet<br>
>> we should not pass up our opportunities in that critical 3%."   --Donald<br>
>> Knuth<br>
>><br>
>><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/" rel="noreferrer" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/</a><br>
>> [1] <a href="https://uwsgi-docs.readthedocs.org/en/latest/Options.html" rel="noreferrer" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/Options.html</a><br>
>> [2] <a href="http://gunicorn.org/" rel="noreferrer" 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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904">+7 (495) 640-49-04</a><br>
> <a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968">+7 (926) 702-39-68</a><br>
> Skype kuklinvv<br>
> 35bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Kind Regards,<br>
Alexander Makarov,<br>
Senior Software Developer,<br>
<br>
Mirantis, Inc.<br>
35b/3, Vorontsovskaya St., 109147, Moscow, Russia<br>
<br>
Tel.: <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904">+7 (495) 640-49-04</a><br>
Tel.: <a href="tel:%2B7%20%28926%29%20204-50-60" value="+79262045060">+7 (926) 204-50-60</a><br>
<br>
Skype: MAKAPOB.AJIEKCAHDP<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>