2a29211052
Changes in python packaging tooling mean that the wsgi_scripts functionality via PBR may not longer function. This patch switches cloudkitty from using the PBR wsgi_scripts method to using a new wsgi module that provides the same behavior as the generated wsgi scripts provided. A related devstack patch enables devstack to setup uWSGI to use the new module path instead of the generated wsgi scripts. For more details see the proposed OpenStack goal [1]. Make grenade job non-voting until backport to stable/2025.1. [1] https://review.opendev.org/c/openstack/governance/+/902807 Change-Id: Id38cfa97699f01be89b37a9ee7a9e3253925e187
30 lines
925 B
YAML
30 lines
925 B
YAML
---
|
|
features:
|
|
- |
|
|
A new module, ``cloudkitty.wsgi``, has been added as a place to gather WSGI
|
|
``application`` objects. This is intended to ease deployment by providing a
|
|
consistent location for these objects. For example, if using uWSGI then
|
|
instead of:
|
|
|
|
.. code-block:: ini
|
|
|
|
[uwsgi]
|
|
wsgi-file = /bin/cloudkitty-api
|
|
|
|
You can now use:
|
|
|
|
.. code-block:: ini
|
|
|
|
[uwsgi]
|
|
module = cloudkitty.wsgi.api:application
|
|
|
|
This also simplifies deployment with other WSGI servers that expect module
|
|
paths such as gunicorn.
|
|
upgrade:
|
|
- |
|
|
The WSGI script ``cloudkitty-api`` has been removed. Deployment tooling
|
|
should instead reference the Python module path for the wsgi module in
|
|
CloudKitty, ``cloudkitty.wsgi.api:application`` if their chosen WSGI server
|
|
supports this (gunicorn, uWSGI, etc.) or implement a .wsgi script
|
|
themselves if not (mod_wsgi).
|