During Pike cycle there was efforts to deploy services under Apache HTTPD. It became clear very quickly that Glance did not operate properly when deployed as bare wsgi app under web server but admin documentation was merged that indicated that being somehow the preferred method. It was added to the doc that in Pike release there was issues in these models. There was never interest nor resources to fix the underlying issues but the doc stayed in place indicating that those issues could be only Pike related when they in matter of fact has got even worse over the time. Due to the fact that Glance is even more relying on eventlet than back then it's time to clarify the docs and make clear it's not adviced deployment model, it won't work and there is no itention to change that. Change-Id: I93dc7c999ff7a180e6b3ff760fa65328b9a883f3 Closes-Bug: #1887994
3.1 KiB
Running Glance in HTTPD
In short Glance will not operate properly if tried to be ran without eventlet and introducing another web server into the mix does not make it any better. This exercise failed without ever having proper interest or resources to fix the underlying issues.
None of the models deploying Glance as bare wsgi app under some httpd are currently adviced.
Since the Pike release Glance has packaged a wsgi script entrypoint that enables you to run it with a real web server like Apache HTTPD or nginx. To deploy this there are several patterns, which all fail different ways. This doc mentions three common ways of trying to deploy Glance with Apache HTTPD.
Warning
As pointed out in the Pike and Queens release notes (see the "Known Issues" section of each), the Glance project team recommends that Glance be run in its normal standalone configuration, particularly in production environments. The full functionality of Glance is not available when Glance is deployed in the manner described in this document. In particular, the interoperable image import functionality does not work under such configuration. See the release notes for details.
uWSGI Server HTTP Mode
This has never worked properly nor it has been of any development focus.
The clearest we can say is just don't do it.
mod_proxy_uwsgi
This has not been doable since Ussuri as we only support Python 3.
In theory the same applies as mod_wsgi but even without chunked encoding the code is still broken under uwsgi.
mod_wsgi
This deployment method is not recommended for using Glance. The
mod_wsgi protocol does not support
Transfer-Encoding: chunked
and therefore makes it
unsuitable for use with Glance. However, you could theoretically deploy
Glance using mod_wsgi but it will fail on any requests that use a
chunked transfer encoding.
Glossary
- uwsgi protocol
-
The native protocol used by the uWSGI server. (The acronym is written in all lowercase on purpose.)
- uWSGI project
-
A project that aims at developing a full stack for building hosting services. It produces software, the uWSGI server, that is exposed in Python code as a module named
uwsgi
.https://uwsgi-docs.readthedocs.io/en/latest/index.html
- mod_wsgi
-
An Apache 2 HTTP server module that supports the Python WSGI specification.
- mod_proxy_uwsgi
-
An Apache 2 HTTP Server module that provides a uwsgi gateway for mod_proxy. It communicates to the uWSGI server using the uwsgi protocol.
- WSGI
-
Web Server Gateway Interface, a Python standard published as PEP 3333.