The standard choice would be Apache+mod_wsgi. The trendy kids nowadays seems to prefer nginx+uwsgi or nginx+gunicorn. Since we are handling authentication in the application itself, not using Apache modules, we can pick a trendier option if we want.

ResultsDB is currently deployed in Apache+mod_wsgi so there is some value in consistency.

I don't have any experience with the nginx approaches to say whether it's a substantially better choice than Apache+mod_wsgi.

However there is one advantage to nginx+gunicorn which is that it lets us switch to the gaiohttp worker type in case we port waiverdb to Python's asyncio in future.

OpenShift 2 defaults to mod_wsgi with some support for running alternative WSGI containers.

OpenShift 3 is kind of laissez faire since it's all Docker containers so you can run anything and everything. Their Django example project contains... a lot of magic. It doesn't actually have anything to specify how the app is actually run, it seems you have to know that it inherits from this Python 3.5 container, which has some deployment options that are tried in order beginning with Gunicorn.

I guess for internal deployment, we'll use Apache+mod_wsgi, right?

We can use whatever we want for the internal deployment. I would definitely want both the Fedora deployment and the internal deployment to use whatever we decide on here.

Does fedora have any existing roles for configuring nigix and uwsgi? I found this blog which it's quite helpful to understand nginx+gunicorn.

https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uwsgi-and-nginx-on-centos-7

From grepping in the Fedora infra ansible repo, it looks like there are no services using nginx+uwsgi currently.

There is one using nginx+gunicorn: Taiga.

Also Fedora infra puts everything behind a reverse proxy (Varnish I think?) so the nginx piece may not be necessary -- we could just run the service in gunicorn and expose that. The only reasons that nginx is recommended in front appears to be to protect against slow client requests, and to serve up static files more efficiently.

http://docs.gunicorn.org/en/stable/deploy.html

But waiverdb doesn't have any static files, and the Varnish proxy already protects against slow clients. (Might need to confirm that.)

Could you take a look at what it would take to deploy this directly into a OpenShift env, skipping PDI altogether (at least for the front-end/REST piece)? If we could show this as a internal OS success story, that'd be a big win for us.

Right, I had OpenShift deployment in mind which is why I mentioned it earlier.

It seems the default choice in OpenShift 3 is for the app to be run inside Gunicorn, with (I assume) some load balancer/reverse proxy in front provided by OpenShift itself.

So it seems like Gunicorn is the way to go. For Fedora we can run it in Gunicorn, possibly with nginx in front if the Varnish reverse proxy is not already enough. Internally we can run it in Gunicorn with nginx and then migrate it to OpenShift later on when that actually exists.

So we seem to have settled on Gunicorn, with deployment in OpenShift for the internal instance (and hopefully also for Fedora infra, see https://pagure.io/fedora-infrastructure/issue/6043). We will need some tweaks to make waiverdb runnable inside Openshift, I am working on these at the moment.

But I think there is nothing left to decide/discuss/solve on this issue right now. We can always adjust our deployment strategy down the track.

PR#46 is for OpenShift deployment fixes and templates.