Open Stack

> -------- Original Message --------
> Subject: Re: [openstack-dev] [requirements] adding uwsgi to global-requirements
> Local Time: December 19, 2017 6:34 PM
> UTC Time: December 19, 2017 11:34 PM
> From: mtreinish at kortar.org
> To: Sam Yaple <sam at yaple.net>, OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
>
> 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.

I did say uwsgi+nginx/apache on the line directly before that. You cannot run wsgi+apache with glance at all (directly) due to the lack of chunked transfer support making a wsgi deploy of glance *require* uwsgi. Though this goes to your support further of not defining how people deploy.

>> 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.

Agreed. I should clarify, I am in no way trying to force anyone to use uwsgi. Quite the opposite. I am talking specifically about those who _choose_ to use uwsgi. Which, as you point out, the gate jobs already do as part of the implementation.

>> 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?

Not to discount the rest of your reply, but it does seem geared toward the idea that this would force people to use uwsgi.

The advantage is quite singular in my opinion, using upper-constraints.txt as a pinning mechanism for testing the same version of uwsgi everywhere. Additionally, projects do consume global-requirements.txt and upper-constraints.txt and build _all_ wheels listed within. If uwsgi is not in that list, it is an external package that must be specified to be built, with appropriate version pinning now ona per-project basis.

The fact that uwsgi is widely used, even as an implementation detail, is the strongest arguement i have for shared version control of it.

>> -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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171219/72956f25/attachment-0001.html>