[openstack-dev] [requirements] adding uwsgi to global-requirements
mtreinish at kortar.org
Tue Dec 19 23:34:40 UTC 2017
On Tue, Dec 19, 2017 at 05:46:34PM -0500, Sam Yaple wrote:
> I wanted to bring up the idea of getting uwsgi into the requirements repo. I seem to recall this being discussed a couple of years back, but for the life of me I cannot find the thread, so forgive me if I am digging up ancient history.
> I would like to see uwsgi in global-requirements.txt and upper-constraints.txt .
> Since the recent goal of running all api's behind WSGI has been mostly accomplished, I have seen a migration toward wsgi based deploys. Some of which use uwsgi+nginx/apache.
> Glance recommends uwsgi  as "the current recommended way to deploy" if the docs are to be believed.
Umm finish the sentence there, it says "with a real web server". The context
there is use uwsgi if you want to run glance with Apache HTTPD, nginx, etc. Not
a general recommendation to use uwsgi. In fact if you read more of the doc it
outlines issues involved with using uwsgi and glance and lots of tradeoffs with
doing that. The wording in the more recent doc might make the situation a bit
clearer.  If you want all the API functionality to work in glance you should
still be using the eventlet server, using WSGI means things like the tasks api
doesn't work. (although TBH, I don't think most people care about that)
> The LOCI project has been including uwsgi (and recommending people use it) since its inception.
> These facts, in my opinion, make a pretty strong case for uwsgi being an indirect dependancy and worthy of inclusion and tracking in the requirements repo.
> My question for the community, are there strong feelings against including uwsgi? If so, why?
For the majority of projects out there we test using the WSGI interface using
uWSGI, but uWSGI isn't actually a requirement. The cross project goal where
we moved all the devstack jobs to use uWSGI was not about using uWSGI, but
about using the standard interfaces for deploying web services under a web
server, the goal is about exposing a WSGI not using uWSGI. The uWSGI part in
the goal is an implementation detail for setting up the gate jobs.
We don't want to dictate how people are deploying the webapps, instead we say
we use the normal interfaces for deploying python webapps. So if your used to
use mod_wsgi with apache, gunicorn + ngix, or uwsgi standalone, etc. you can do
that. uwsgi in this context is the same as apache. It's not actually a
requirement for any project, you can install and run everything without it, and
in fact many people do.
The other half of this is that just pip installing uwsgi is not always enough
to actually leverage using it with a webserver. You also need the web server
support for talking to uwsgi. If that's how you use choose to deploy it, which
is not always straightforward. For example, take a look at how it is installed
in devstack to make uwsgi work properly with apache.  There are also other
concerns using pip to install uwsgi. uWSGI is a C application and not actually
a python project. It also supports running applications in several languages,
not just python. The pypi published install is kind of a hack to download the
tarball and compile the application with only the python bindings compiled.
The setup.py literally calls out to gcc to build it, it's essentially a makefile
written in python. 
So what advantage do we get by adding it to global requirements when it's not
actually a requirement for any project, nor is it even python code?
>  https://docs.openstack.org/glance/pike/admin/apache-httpd.html#uwsgi
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the OpenStack-dev