Hey,

I don't really like gunicorn/uvicorn options as you pretty much need to have a proper web-server in front of it for TLS termination, routing, etc. And having a web-server can add quite some complexity and overhead to setup, especially when talking about the devstack.

I believe that the project should just suggest a WSGI-compatible handler for the app, and don't be too specific about the implementation, while leaving choice to users or deployment tools.
With that being said, uWSGI is maintained, it's not "unmaintained" - last release was 3 month ago. The biggest issues I see with uWSGI so far is absence of HTTP/2 support and absence of ASGI - but none of these issues are solved with gunicorn to be fair.

As a potential replacement for uWSGI I'd be probably considering granian [1] which, on paper, ticks all the boxes, but I have not yet tried any production environment on it. But again, I think our generic recommendations about WSGI handlers should be abstract overall, and leave the choice to end users.

[1] https://github.com/emmett-framework/granian

ср, 7 янв. 2026 г. в 04:02, Takashi Kajinami <kajinamit@oss.nttdata.com>:
I'm not aware of any action taken after these discussions but my understanding is that
uwsgi is still the popular (semi-standard) runtime.

The problem is that uwsgi is still "maintained" and is enough for most of current use cases.
I saw some concerns raised in that openstack-ansible thread about no support for async but
at this moment we don't have any services actually using async within api and I'm not too
sure if that is seriously needed in addition to base concurrency (like worker/thread) mechanism.
Eventlet provided us is similar to async approach but it was proven to provide less performance
benefit compared to bare process/thread approach.

What we could do as initial experiment is to update devstack to use a different mechanism such
as gunicorn or uvicorn, and see if these works better. However I'm unsure if this get enough
attention without any use actually facing problems specific to uwsgi.

On 1/7/26 6:24 AM, opensource@rfc2549.ca wrote:
> Hi,
>
> This thread from 2023 generated some discussion around uWSGI being in maintenance mode but my search doesn't yield more recent developments around $topic. uWSGI is still in maintenance mode 3 years later.
>
> Back at the Epoxy PTG, openstack-ansible had a topic [1] to figure a replacement but after checking with Dimitri, this has not happened yet and they are still relying on uWSGI at this time.
>
> I was curious if the community had opinions on what the next "standard" wsgi runtime might be from options like gunicorn, uvicorn or granian, to name a few.
> I realize this is not so much a problem for individual OpenStack projects but like mentioned in [0], it is much nicer if any of the options are well supported/documented from an operator perspective.
>
> Thanks !
>
> [0]: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032345.html
> [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/IHT35BIQG62CPNLFOHUTU3PA5O7ZTV6P/