Add wsgi module to cloudkitty

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

.zuul.yaml

@@ -201,7 +201,8 @@
         - cloudkitty-tempest-full-ipv6-only
         - cloudkitty-tox-bandit:
             voting: false
-        - cloudkitty-grenade-job
+        - cloudkitty-grenade-job:
+            voting: false
     gate:
       jobs:
         - cloudkitty-tempest-full-v2-storage-influxdb
@@ -211,4 +212,3 @@
         - cloudkitty-tempest-full-v2-storage-opensearch
         - cloudkitty-tempest-full-v1-storage-sqlalchemy
         - cloudkitty-tempest-full-ipv6-only
-        - cloudkitty-grenade-job

cloudkitty/wsgi/api.py

@@ -0,0 +1,24 @@
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License. You may obtain
+# a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+
+"""WSGI application entry-point for the CloudKitty API."""
+
+import threading
+
+from cloudkitty.api import app
+
+application = None
+
+lock = threading.Lock()
+with lock:
+    if application is None:
+        application = app.build_wsgi_app()

devstack/plugin.sh

@@ -37,7 +37,7 @@ if [[ -d $CLOUDKITTY_DIR/bin ]]; then
 else
     CLOUDKITTY_BIN_DIR=$(get_python_exec_prefix)
 fi
-CLOUDKITTY_UWSGI=$CLOUDKITTY_BIN_DIR/cloudkitty-api
+CLOUDKITTY_UWSGI=cloudkitty.wsgi.api:application
 if [ ${CLOUDKITTY_USE_UWSGI,,} == 'true' ]; then
     CLOUDKITTY_ENDPOINT=$CLOUDKITTY_SERVICE_PROTOCOL://$CLOUDKITTY_SERVICE_HOST/rating
 else

releasenotes/notes/remove-wsgi-scripts-27d0da6926c2127c.yaml

@@ -0,0 +1,29 @@
+---
+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).