Open Stack

Hi,

Morgan gave the perfect case why operators want to use uWSGI. Let's imagine
a future when all openstack services will work as mod_wsgi processes under
apache. It's like to put all eggs in one basket. If you need to reconfigure
one service on controller it may affect another service. For instance,
sometimes operators need to increase number of Threads/Processes for wsgi
or add new virtual host to apache. That will require graceful or cold
restart of apache. It affects other services. Another case, internal
problems in mod_wsgi where it may lead to apache crash affecting all
services.

uWSGI/gunicorn model is safer as in this case apache is reverse_proxy only.
This  model gives flexibility for operators. They may use apache/nginx as
proxy or load balancer. Stop or crash of one service won't lead to downtime
of other services. The complexity of OpenStack management will be easier
and friendly.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Fri, Sep 18, 2015 at 3:44 PM, Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> There is and has been desire to support uWSGI and other alternatives to
> mod_wsgi. There are a variety of operational reasons to consider uWSGI
> and/or gunicorn behind apache most notably to facilitate easier management
> of the processes independently of the webserver itself. With mod_wsgi the
> processes are directly tied to the apache server where as with uWSGI and
> gunicorn you can manage the various services independently and/or with
> differing VENVs more easily.
>
> There are potential other concerns that must be weighed when considering
> which method of deployment to use. I hope we have clear documentation
> within the next cycle (and possible choices for the gate) for utilizing
> uWSGI and/or gunicorn.
>
> --Morgan
>
> Sent via mobile
>
> On Sep 18, 2015, at 06:12, Adam Young <ayoung at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/495225a4/attachment.html>