<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 09/25/2015 07:09 AM, Sergii
Golovatiuk wrote:<br>
</div>
<blockquote
cite="mid:CA+HkNVsjYj3UXtR2eJGVSvDECuFaaHRDBN-mp+YXe2nh4Y3TWQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
There are some fallacies here:<br>
<br>
1. OpenStack services should all be on the same machine.<br>
2. OpenStack web services should run on ports other than 443.<br>
<br>
I think both of these are ideas who's time have come and gone.<br>
<br>
If you have a single machine, run them out of separate containers.
That allows different services to work with different versions of
the libraries. It lets you mix a newer Keystone with older
everything else.<br>
<br>
If everything is on port 443, you need a single web server at the
front end to multiplex it; uWSGI or any other one does not obviate
that.<br>
<br>
<br>
There are no good ports left in /etc/services; stop trying to
reserve new ones for the web. If you need to run on a web service,
you need to be able to get through firewalls. You need to run on
standard ports. Run on 443.<br>
<br>
Keystone again is a great example of this: it has two ports: 5000
and 35357.<br>
<br>
port 5000 in /etc/services is<br>
<br>
commplex-main 5000/tcp<br>
<br>
and port 35357 is smack dab in the middle of the ephemeral range.<br>
<br>
<br>
Again, so long as the web server supports the cryptographic secure
mechanisms, I don't care what one you chose. But The idea of use
going to Keystone and getting a bearer token as the basis for
security is immature; we should be doing the following on every
call:<br>
<br>
1. TLS<br>
2. Cryptographic authentication.<br>
<br>
<br>
They can be together or split up.<br>
<br>
So, lets get everything running inside Apache, and, at the same
time, push our other favorite web servers to support the necessary
pieces to make OpenStack and the Web secure.<br>
<br>
<br>
<blockquote
cite="mid:CA+HkNVsjYj3UXtR2eJGVSvDECuFaaHRDBN-mp+YXe2nh4Y3TWQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</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 3:44 PM, Morgan
Fainberg <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>--Morgan<br>
<br>
Sent via mobile</div>
<div>
<div class="h5">
<div><br>
On Sep 18, 2015, at 06:12, Adam Young <<a
moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ayoung@redhat.com">ayoung@redhat.com</a></a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>On 09/17/2015 10:04 PM, Jim Rollenhagen
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote:
</pre>
<blockquote type="cite">
<pre>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?
</pre>
</blockquote>
<pre>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.</pre>
</blockquote>
<br>
I am not aware of that. It has been the workhorse
of the Python/wsgi world for a while, and we use
it heavily.<br>
<br>
<blockquote type="cite">
<pre>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. :)</pre>
</blockquote>
<br>
Again, switching web servers is as likely to
introduce as to solve 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 is designed to scale
horizontally first. Before advocating switching
to a 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 for a while.<br>
<br>
If Keystone is having performance issues, it is
most likely at the database layer, not the web
server.<br>
<br>
<br>
<br>
"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 <em>should</em> forget about small
efficiencies, say about 97% of the time: <strong>premature
optimization is the root of all evil.</strong>
Yet we should not pass up our opportunities in
that critical 3%." --Donald Knuth<br>
<br>
<br>
<br>
<blockquote type="cite">
<pre>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] <a moz-do-not-send="true" href="https://uwsgi-docs.readthedocs.org/en/latest/" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/</a>
[1] <a moz-do-not-send="true" href="https://uwsgi-docs.readthedocs.org/en/latest/Options.html" target="_blank">https://uwsgi-docs.readthedocs.org/en/latest/Options.html</a>
[2] <a moz-do-not-send="true" href="http://gunicorn.org/" target="_blank">http://gunicorn.org/</a>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>__________________________________________________________________________</span><br>
<span>OpenStack Development Mailing List (not for
usage questions)</span><br>
<span>Unsubscribe: <a moz-do-not-send="true"
href="mailto:OpenStack-dev-request@lists.openstack.org"
target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br>
<span><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
</div>
<br>
</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>