> -------- 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: mtrein...@kortar.org
> To: Sam Yaple <s...@yaple.net>, OpenStack Development Mailing List (not for
> usage questions) <openstack-dev@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
__________________________________________________________________________
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
