
Move the "Migrate from wsgi scripts to module paths" goal from proposed to completed in the 2025.2 cycle. This goal focused on migrating OpenStack services from using PBR's wsgi_scripts entrypoint to Python module paths for WSGI applications, addressing compatibility issues with newer Python packaging tools. While not officially selected, we were forced to make changes to match the changes in python packaging tools. Change-Id: I38963569d60b67faf1b6af520a1fc53576c6519e Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
79 lines
3.0 KiB
ReStructuredText
79 lines
3.0 KiB
ReStructuredText
=========================================
|
|
Migrate from wsgi scripts to module paths
|
|
=========================================
|
|
|
|
We have long supported automated generation of WSGI scripts, which are Python
|
|
scripts that contain an ``application`` object as described in `PEP-333`__.
|
|
This automated generation was facilitated by PBR through the use of
|
|
``wsgi_scripts`` entrypoint declared in ``setup.cfg`` or ``setup.py``.
|
|
|
|
As a result of multiple changes in the Python packaging ecosystem, primarily
|
|
driven by `PEP-517`__, the approach we have used to implement this
|
|
functionality will eventually break. We are rapidly approaching the point where
|
|
it will no longer be possible to continue to support without likely large
|
|
investment in PBR.
|
|
|
|
This investment is hard to justify given the WSGI script approach is not
|
|
necessary for uWSGI and is not supported by gunicorn. Both of these utilities
|
|
instead support for specifying Python module paths. That is to say, instead of
|
|
providing a filesystem path to a Python script, we can provide a Python module
|
|
path to an ``application`` object. In more concrete terms, a uWSGI
|
|
configuration that currently looks like so:
|
|
|
|
.. code-block:: ini
|
|
|
|
[uwsgi]
|
|
wsgi-file = /bin/nova-api-wsgi
|
|
|
|
can also be configured as:
|
|
|
|
.. code-block:: ini
|
|
|
|
[uwsgi]
|
|
module = nova.wsgi.osapi_compute:application
|
|
|
|
All projects that expose a WSGI server and make use of PBR's ``wsgi_scripts``
|
|
functionality should provide a new ``<service>.wsgi`` module. This module
|
|
should contain one or more modules, each corresponding to an individual WSGI
|
|
server exposed by the service. Each of these server modules should contain an
|
|
``application`` object suitable for invocation by a WSGI reverse proxy server.
|
|
|
|
Services may choose to remove the ``wsgi_scripts`` entrypoint immediately upon
|
|
migration or wait a cycle to remove it. However, these entrypoints will soon
|
|
start to fail with newer versions of pip and setuptools thus they should not be
|
|
retained indefinitely.
|
|
|
|
Champion
|
|
========
|
|
|
|
Stephen Finucane (stephenfin)
|
|
|
|
Gerrit Topic
|
|
============
|
|
|
|
To facilitate tracking, commits related to this goal should use the
|
|
gerrit topic::
|
|
|
|
remove-wsgi_scripts
|
|
|
|
Completion Criteria
|
|
===================
|
|
|
|
#. All official OpenStack service projects should provide one or more
|
|
``<service>.wsgi.<server>`` modules, each containing an ``application``
|
|
object.
|
|
|
|
Current State / Anticipated Impact
|
|
==================================
|
|
|
|
Thus far, patches have been proposed against Nova and DevStack to demonstrate
|
|
the impact of this change. As services start implementing their own
|
|
``<service>.wsgi`` module, all deployment tools including DevStack will need to
|
|
to switch from WSGI script-based configuration to Python module path-based
|
|
configuration. From the initial work on the Nova and DevStack as well as
|
|
discussions with relevant people working on deployment tooling, it is expected
|
|
that the overall size of this effort will be minimal.
|
|
|
|
.. __: https://peps.python.org/pep-0333/
|
|
.. __: https://peps.python.org/pep-0517/
|