[tc][ops] Any consensus for what's next after uWSGI ?
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... [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
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... [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
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.
Hi,
This thread from 2023 generated some discussion around uWSGI being in
On 1/7/26 6:24 AM, opensource@rfc2549.ca wrote: 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"
I realize this is not so much a problem for individual OpenStack
wsgi runtime might be from options like gunicorn, uvicorn or granian, to name a few. 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...
[1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
On 20/01/2026 08:37, Dmitriy Rabotyagov wrote:
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. right so opentack does not specify a wsgi server today
uwsgi and Apache mod_wsgi are the too most commonly used but in principal you should be able to use any wsgi compliant server to provide the wsgi runtime. i have not really looked at granian before but its bsd liscneed as you said it support wsgi and asgi although i dont know if we have any project that have currently moved to using async io for the rest api but i guess it makes that possible. importantly it does support just specifying the wsgi applcation module path instead of requiring a wsgi script to run the applciation |granian --interface wsgi main:app and its avaible via pypi so if we wanted to do an experiment with it in devstack it should be relatively simple to swap out uswig for it. similarly any installer like kolla or osa should be able to leverage it. on the devstack side wit a little work we could even make that a little more easily plugable you can write a devstack plugin to day that just redefines the functions we use to manage uwsgi but if there was an interest in testing different runtimes we could actually make that possible to do. for the most part project ideally woudl not depend on the implementation details of any specific wsgi server.|
[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... > [1]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
i have not really looked at granian before but its bsd liscneed as you said it support wsgi and asgi although i dont know if we have any project that have currently moved to using async io for the rest api but i guess it makes that possible.
Skyline is using FastAPI, so it's asgi. That's all for now, I as far as I know. вт, 20 янв. 2026 г. в 13:30, Sean Mooney <smooney@redhat.com>:
On 20/01/2026 08:37, Dmitriy Rabotyagov wrote:
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. right so opentack does not specify a wsgi server today
uwsgi and Apache mod_wsgi are the too most commonly used but in principal you should be able to use any wsgi compliant server to provide the wsgi runtime.
i have not really looked at granian before but its bsd liscneed as you said it support wsgi and asgi although i dont know if we have any project that have currently moved to using async io for the rest api but i guess it makes that possible.
importantly it does support just specifying the wsgi applcation module path instead of requiring a wsgi script to run the applciation
|granian --interface wsgi main:app and its avaible via pypi so if we wanted to do an experiment with it in devstack it should be relatively simple to swap out uswig for it. similarly any installer like kolla or osa should be able to leverage it. on the devstack side wit a little work we could even make that a little more easily plugable you can write a devstack plugin to day that just redefines the functions we use to manage uwsgi but if there was an interest in testing different runtimes we could actually make that possible to do. for the most part project ideally woudl not depend on the implementation details of any specific wsgi server.|
[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...
> [1]:
https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
participants (4)
-
Dmitriy Rabotyagov
-
opensource＠rfc2549.ca
-
Sean Mooney
-
Takashi Kajinami