Please consider that we use some apache mods - does nginx/uwsgi/gunicorn have oauth, shibboleth & openid support?
On Fri, Sep 18, 2015 at 4:54 PM, Vladimir Kuklin <[email protected]> wrote: > Folks > > I think we do not need to switch to nginx-only or consider any kind of war > between nginx and apache adherents. Everyone should be able to use > web-server he or she needs without being pinned to the unwanted one. It is > like Postgres vs MySQL war. Why not support both? > > May be someone does not need something that apache supports and nginx not > and needs nginx features which apache does not support. Let's let our users > decide what they want. > > And the first step should be simple here - support for uwsgi. It will allow > for usage of any web-server that can work with uwsgi. It will allow also us > to check for the support of all apache-like bindings like SPNEGO or whatever > and provide our users with enough info on making decisions. I did not > personally test nginx modules for SAML and SPNEGO, but I am pretty confident > about TLS/SSL parts of nginx. > > Moreover, nginx will allow you to do things you cannot do with apache, e.g. > do smart load balancing, which may be crucial for high-loaded installations. > > > On Fri, Sep 18, 2015 at 4:12 PM, Adam Young <[email protected]> wrote: >> >> On 09/17/2015 10:04 PM, Jim Rollenhagen wrote: >> >> On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote: >> >> In the fuel project, we recently ran into a couple of issues with Apache2 >> + >> mod_wsgi as we switched Keystone to run . Please see [1] and [2]. >> >> Looking deep into Apache2 issues specifically around "apache2ctl graceful" >> and module loading/unloading and the hooks used by mod_wsgi [3]. I started >> wondering if Apache2 + mod_wsgi is the "right" solution and if there was >> something else better that people are already using. >> >> One data point that keeps coming up is, all the CI jobs use Apache2 + >> mod_wsgi so it must be the best solution....Is it? If not, what is? >> >> Disclaimer: it's been a while since I've cared about performance with a >> web server in front of a Python app. >> >> IIRC, mod_wsgi was abandoned for a while, but I think it's being worked >> on again. In general, I seem to remember it being thought of as a bit >> old and crusty, but mostly working. >> >> >> I am not aware of that. It has been the workhorse of the Python/wsgi >> world for a while, and we use it heavily. >> >> At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0] >> and saw a significant performance increase. This was a Django app. uwsgi >> is fairly straightforward to operate and comes loaded with a myriad of >> options[1] to help folks make the most of it. I've played with Ironic >> behind uwsgi and it seemed to work fine, though I haven't done any sort >> of load testing. I'd encourage folks to give it a shot. :) >> >> >> Again, switching web servers is as likely to introduce as to solve >> problems. If there are performance issues: >> >> 1. Idenitfy what causes them >> 2. Change configuration settings to deal with them >> 3. Fix upstream bugs in the underlying system. >> >> >> Keystone is not about performance. Keystone is about security. The cloud >> is designed to scale horizontally first. Before advocating switching to a >> difference web server, make sure it supports the technologies required. >> >> >> 1. TLS at the latest level >> 2. Kerberos/GSSAPI/SPNEGO >> 3. X509 Client cert validation >> 4. SAML >> >> OpenID connect would be a good one to add to the list; Its been requested >> for a while. >> >> If Keystone is having performance issues, it is most likely at the >> database layer, not the web server. >> >> >> >> "Programmers waste enormous amounts of time thinking about, or worrying >> about, the speed of noncritical parts of their programs, and these attempts >> at efficiency actually have a strong negative impact when debugging and >> maintenance are considered. We should forget about small efficiencies, say >> about 97% of the time: premature optimization is the root of all evil. Yet >> we should not pass up our opportunities in that critical 3%." --Donald >> Knuth >> >> >> >> Of course, uwsgi can also be ran behind Apache2, if you'd prefer. >> >> gunicorn[2] is another good option that may be worth investigating; I >> personally don't have any experience with it, but I seem to remember >> hearing it has good eventlet support. >> >> // jim >> >> [0] https://uwsgi-docs.readthedocs.org/en/latest/ >> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html >> [2] http://gunicorn.org/ >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com > www.mirantis.ru > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
