On Tue, Dec 19, 2017 at 05:46:34PM -0500, Sam Yaple wrote: > Hello, > > 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 [0] 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. [1] 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[2] 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. [3] 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[4], 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. [5][6] 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? -Matt Treinish > > [0] https://docs.openstack.org/glance/pike/admin/apache-httpd.html#uwsgi [1] https://docs.openstack.org/glance/latest/admin/apache-httpd.html [2] https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html [3] https://github.com/openstack-dev/devstack/blob/57ddd7c1613208017728c50370d2e259c072d511/lib/apache#L76-L116 [4] http://uwsgi-docs.readthedocs.io/en/latest/LanguagesAndPlatforms.html [5] https://github.com/unbit/uwsgi/blob/master/setup.py [6] https://github.com/unbit/uwsgi/blob/master/uwsgiconfig.py#L254-L278
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
