> -------- Original Message --------
> Subject: Re: [openstack-dev] [requirements] adding uwsgi to
> global-requirements
> Local Time: December 19, 2017 9:57 PM
> UTC Time: December 20, 2017 2:57 AM
> 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 07:50:59PM -0500, Sam Yaple wrote:
>
>>> -------- 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.
>>
>> Except global requirements is not a generic packaging tool or installer,
>> it's very
>> specifically a place to store common requirements for python between
>> OpenStack
>> projects. Mostly as a workaround for the lack of real dependency solver in
>> pip.
>> Nothing is going to ever have uwsgi in it's requirements file. (it can't
>> because
>> uwsgi doesn't have any standalone python) Doing this would be like making a
>> shim
>> apache python package which would compile it from source and install it all
>> using setup.py and using that instead of a distro package.
These are definitely valid points and I accept your reasoning. I am happy to
drop the subject based on that paragraph alone.
I feel like there might have been a bit of unneeded conflict in this
conversation, but perhaps thats just me reading too much into the text. If
there was any, I apologize for my part in it.
Thanks,
SamYaple
>> -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
