<div><br></div><div class="protonmail_signature_block protonmail_signature_block-empty"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><br></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: Re: [openstack-dev] [requirements] adding uwsgi to global-requirements<br></div><div>Local Time: December 19, 2017 9:57 PM<br></div><div>UTC Time: December 20, 2017 2:57 AM<br></div><div>From: mtreinish@kortar.org<br></div><div>To: Sam Yaple <sam@yaple.net>, OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org><br></div><div><br></div><div>On Tue, Dec 19, 2017 at 07:50:59PM -0500, Sam Yaple wrote:<br></div><blockquote><blockquote><div><div>-------- Original Message --------<br></div><div> Subject: Re: [openstack-dev] [requirements] adding uwsgi to global-requirements<br></div><div> Local Time: December 19, 2017 6:34 PM<br></div><div> UTC Time: December 19, 2017 11:34 PM<br></div><div> From: <a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a><br></div><div> To: Sam Yaple <a href="mailto:sam@yaple.net">sam@yaple.net</a>, OpenStack Development Mailing List (not for usage questions) <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br></div></div><div>On Tue, Dec 19, 2017 at 05:46:34PM -0500, Sam Yaple wrote:<br></div><blockquote><div><div>Hello,<br></div><div> 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.<br></div><div> I would like to see uwsgi in global-requirements.txt and upper-constraints.txt .<br></div><div> 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.<br></div><div> Glance recommends uwsgi [0] as "the current recommended way to deploy" if the docs are to be believed.<br></div></div><div><div>Umm finish the sentence there, it says "with a real web server". The context<br></div><div> there is use uwsgi if you want to run glance with Apache HTTPD, nginx, etc. Not<br></div><div> a general recommendation to use uwsgi.<br></div></div></blockquote></blockquote><div>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 <i>require</i> uwsgi. Though this goes to your support further of not defining how people deploy.<br></div><blockquote><blockquote><div><div>In fact if you read more of the doc it<br></div><div> outlines issues involved with using uwsgi and glance and lots of tradeoffs with<br></div><div> doing that. The wording in the more recent doc might make the situation a bit<br></div><div> clearer. [1] If you want all the API functionality to work in glance you should<br></div><div> still be using the eventlet server, using WSGI means things like the tasks api<br></div><div> doesn't work. (although TBH, I don't think most people care about that)<br></div><div> The LOCI project has been including uwsgi (and recommending people use it) since its inception.<br></div><div> 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.<br></div><div> My question for the community, are there strong feelings against including uwsgi? If so, why?<br></div></div><div><div>For the majority of projects out there we test using the WSGI interface using<br></div><div> uWSGI, but uWSGI isn't actually a requirement. The cross project goal[2] where<br></div><div> we moved all the devstack jobs to use uWSGI was not about using uWSGI, but<br></div><div> about using the standard interfaces for deploying web services under a web<br></div><div> server, the goal is about exposing a WSGI not using uWSGI. The uWSGI part in<br></div><div> the goal is an implementation detail for setting up the gate jobs.<br></div></div></blockquote></blockquote><div>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 <i>choose</i> to use uwsgi. Which, as you point out, the gate jobs already do as part of the implementation.<br></div><blockquote><blockquote><div><div>We don't want to dictate how people are deploying the webapps, instead we say<br></div><div> we use the normal interfaces for deploying python webapps. So if your used to<br></div><div> use mod_wsgi with apache, gunicorn + ngix, or uwsgi standalone, etc. you can do<br></div><div> that. uwsgi in this context is the same as apache. It's not actually a<br></div><div> requirement for any project, you can install and run everything without it, and<br></div><div> in fact many people do.<br></div></div><div><div>The other half of this is that just pip installing uwsgi is not always enough<br></div><div> to actually leverage using it with a webserver. You also need the web server<br></div><div> support for talking to uwsgi. If that's how you use choose to deploy it, which<br></div><div> is not always straightforward. For example, take a look at how it is installed<br></div><div> in devstack to make uwsgi work properly with apache. [3] There are also other<br></div><div> concerns using pip to install uwsgi. uWSGI is a C application and not actually<br></div><div> a python project. It also supports running applications in several languages[4],<br></div><div> not just python. The pypi published install is kind of a hack to download the<br></div><div> tarball and compile the application with only the python bindings compiled.<br></div><div> The <a href="http://setup.py">setup.py</a> literally calls out to gcc to build it, it's essentially a makefile<br></div><div> written in python. [5][6]<br></div></div><div><div>So what advantage do we get by adding it to global requirements when it's not<br></div><div> actually a requirement for any project, nor is it even python code?<br></div></div></blockquote></blockquote><div>Not to discount the rest of your reply, but it does seem geared toward the idea that this would force people to use uwsgi.<br></div><div>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 <i>all</i> 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.<br></div><div><div>The fact that uwsgi is widely used, even as an implementation detail, is the strongest arguement i have for shared version control of it.<br></div><div> <br></div><div> Except global requirements is not a generic packaging tool or installer, it's very<br></div><div> specifically a place to store common <i>requirements</i> for python between OpenStack<br></div><div> projects. Mostly as a workaround for the lack of real dependency solver in pip.<br></div><div> Nothing is going to ever have uwsgi in it's requirements file. (it can't because<br></div><div> uwsgi doesn't have any standalone python) Doing this would be like making a shim<br></div><div> apache python package which would compile it from source and install it all<br></div><div> using <a href="http://setup.py">setup.py</a> and using that instead of a distro package.<br></div><div><br></div></div></blockquote></blockquote><div>These are definitely valid points and I accept your reasoning. I am happy to drop the subject based on that paragraph alone.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Thanks,<br></div><div>SamYaple<br></div><blockquote class="protonmail_quote" type="cite"><blockquote><div><div> <br></div><div> -Matt Treinish<br></div></div><blockquote><blockquote><div><div>[0] <a href="https://docs.openstack.org/glance/pike/admin/apache-httpd.html#uwsgi">https://docs.openstack.org/glance/pike/admin/apache-httpd.html#uwsgi</a><br></div><div> [1] <a href="https://docs.openstack.org/glance/latest/admin/apache-httpd.html">https://docs.openstack.org/glance/latest/admin/apache-httpd.html</a><br></div><div> [2] <a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html">https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html</a><br></div><div> [3] <a href="https://github.com/openstack-dev/devstack/blob/57ddd7c1613208017728c50370d2e259c072d511/lib/apache#L76-L116">https://github.com/openstack-dev/devstack/blob/57ddd7c1613208017728c50370d2e259c072d511/lib/apache#L76-L116</a><br></div><div> [4] <a href="http://uwsgi-docs.readthedocs.io/en/latest/LanguagesAndPlatforms.html">http://uwsgi-docs.readthedocs.io/en/latest/LanguagesAndPlatforms.html</a><br></div><div> [5] <a href="https://github.com/unbit/uwsgi/blob/master/setup.py">https://github.com/unbit/uwsgi/blob/master/setup.py</a><br></div><div> [6] <a href="https://github.com/unbit/uwsgi/blob/master/uwsgiconfig.py#L254-L278">https://github.com/unbit/uwsgi/blob/master/uwsgiconfig.py#L254-L278</a><br></div></div></blockquote></blockquote></blockquote></blockquote><div><br></div>