[ops][api][all] What are we going to do about pastedeploy usage?
oslo.service is going through a lot of churn right now as part of the eventlet migration. We recently noticed that some unrelated WSGI routing code had been inadvertently deprecated, and moved to undeprecate this [1]. In the long-term, however, this code doesn't really belong in oslo.service and should be moved elsewhere. I took a stab at bootstrapping an oslo.wsgi package, and after some hacking I arrived at a dependencies list containing the following: * Paste [2] * PasteDeploy [3] * Routes [4] * WebOb [5] As some of you might know, all of these packages are minimally maintained bordering on unmaintained. I'm not entirely sure we want to want to bootstrap a new project using these libraries as opposed to migrating off of them. My question is this: how important is the pastedeploy framework and the paste.ini files nowadays, particularly for deployers? While their use is relatively consistent across projects (see below), not every service uses them and for those that don't, I personally haven't heard complaints about their absence. Rather than migrating the pastedeploy stuff elsewhere, would it make more sense for affected projects to simply define a static set of middleware (with some config knobs for those we want to be able to enable/disable) and call it a day? Cheers, Stephen PS: This topic came up about 18 months ago [6], but we don't appear to have reached a conclusion. Thus my bringing it up again. [1] https://review.opendev.org/c/openstack/oslo.service/+/954055 [2] https://pypi.org/project/Paste/#history [3] https://pypi.org/project/PasteDeploy/#history [4] https://pypi.org/project/Routes/#history [5] https://pypi.org/project/WebOb/#history [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... --- fwict, the following services all rely on this combo to build their own frameworks, with Nova most likely the progenitor in each case (I'm guessing) * Nova * Barbican * Cinder * Designate * Freezer * Glance * Heat * Manila * Monasca * Neutron * Swift * Trove * Vitrage * Watcher The following services do *not* use these libraries: * Cyborg (pecan) * Ironic (pecan) * Keystone (Flask + Flask-RESTful, with some webob) * Magnum (pecan) * Masakari (homegrown framework using webob) * Zaqar (falcon) * Zun (Flask)
On 17/07/2025 13:37, Stephen Finucane wrote:
oslo.service is going through a lot of churn right now as part of the eventlet migration. We recently noticed that some unrelated WSGI routing code had been inadvertently deprecated, and moved to undeprecate this [1]. so honestly while i think we should likely move off that stack to fastapi or flask ectra im not sure we should do this as a community until the eventlet removal
goal is completed. the main thing that paste gave that other frameworks didn't at the time was the ability to configure middleware pipeline via a simple declarative file.
In the long-term, however, this code doesn't really belong in oslo.service and should be moved elsewhere. I took a stab at bootstrapping an oslo.wsgi package, and after some hacking I arrived at a dependencies list containing the following:
* Paste [2] * PasteDeploy [3] * Routes [4] * WebOb [5] long term i think we could consider all of those to be tech debt that we want to
move off of right. we discussed this briefly int eh context of the eventlet removal 18 month ago as you noted but that is likely not the tech stack we want an oslo.wsgi to use long term.
As some of you might know, all of these packages are minimally maintained bordering on unmaintained. I'm not entirely sure we want to want to bootstrap a new project using these libraries as opposed to migrating off of them.
My question is this: how important is the pastedeploy framework and the paste.ini files nowadays, particularly for deployers? i would be very interested to see ops feedback here too as that ignoring time for a moment is the only gap i personally see with moving to a better maintained
exactly this. project like fastapi or flask for nova at least. flask is already used by keystone and neutron i think. if i had time i would also like to move watcher off of its current PasteDeploy + pecan + WebOb + WSME stack to fastapi or flask pecan had a long period of inactivity. now it has picked back up in 2025 so its not in a bad place but WebOb, WSME and PasteDeploy is defintly tech debt.
While their use is relatively consistent across projects (see below), not every service uses them and for those that don't, I personally haven't heard complaints about their absence. Rather than migrating the pastedeploy stuff elsewhere, would it make more sense for affected projects to simply define a static set of middleware (with some config knobs for those we want to be able to enable/disable) and call it a day? +1 my inclination was to just have a comma separate list of middle-ware to run in order as part of the standard service config.
default to what is enabled in paste today. if need provide a way to load extra middle-ware using https://opendev.org/openstack/stevedore the same way we do plugins in the rest of openstack.
Cheers, Stephen
PS: This topic came up about 18 months ago [6], but we don't appear to have reached a conclusion. Thus my bringing it up again.
[1] https://review.opendev.org/c/openstack/oslo.service/+/954055
I'm glad you spotted this as yes only the eventlet web-sever part was intended to be deprecated.
[2] https://pypi.org/project/Paste/#history [3] https://pypi.org/project/PasteDeploy/#history [4] https://pypi.org/project/Routes/#history [5] https://pypi.org/project/WebOb/#history [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
---
fwict, the following services all rely on this combo to build their own frameworks, with Nova most likely the progenitor in each case (I'm guessing)
* Nova * Barbican * Cinder * Designate * Freezer * Glance * Heat * Manila * Monasca * Neutron * Swift * Trove * Vitrage * Watcher
The following services do *not* use these libraries:
* Cyborg (pecan) * Ironic (pecan) * Keystone (Flask + Flask-RESTful, with some webob) * Magnum (pecan) * Masakari (homegrown framework using webob) * Zaqar (falcon) * Zun (Flask)
On 7/17/25 11:24 PM, Sean Mooney wrote:
On 17/07/2025 13:37, Stephen Finucane wrote:
oslo.service is going through a lot of churn right now as part of the eventlet migration. We recently noticed that some unrelated WSGI routing code had been inadvertently deprecated, and moved to undeprecate this [1]. so honestly while i think we should likely move off that stack to fastapi or flask ectra im not sure we should do this as a community until the eventlet removal
goal is completed.
the main thing that paste gave that other frameworks didn't at the time was the ability to configure middleware pipeline via a simple declarative file.
In the long-term, however, this code doesn't really belong in oslo.service and should be moved elsewhere. I took a stab at bootstrapping an oslo.wsgi package, and after some hacking I arrived at a dependencies list containing the following:
* Paste [2] * PasteDeploy [3] * Routes [4] * WebOb [5] long term i think we could consider all of those to be tech debt that we want to
move off of right.
we discussed this briefly int eh context of the eventlet removal 18 month ago as you noted but that is likely not the tech stack we want an oslo.wsgi to use long term.
As some of you might know, all of these packages are minimally maintained bordering on unmaintained. I'm not entirely sure we want to want to bootstrap a new project using these libraries as opposed to migrating off of them.
exactly this.
My question is this: how important is the pastedeploy framework and the paste.ini files nowadays, particularly for deployers? i would be very interested to see ops feedback here too as that ignoring time for a moment is the only gap i personally see with moving to a better maintained project like fastapi or flask
for nova at least. flask is already used by keystone and neutron i think.
if i had time i would also like to move watcher off of its current PasteDeploy + pecan + WebOb + WSME stack to fastapi or flask
pecan had a long period of inactivity. now it has picked back up in 2025 so its not in a bad place but WebOb, WSME and PasteDeploy is defintly tech debt.
While their use is relatively consistent across projects (see below), not every service uses them and for those that don't, I personally haven't heard complaints about their absence. Rather than migrating the pastedeploy stuff elsewhere, would it make more sense for affected projects to simply define a static set of middleware (with some config knobs for those we want to be able to enable/disable) and call it a day? +1 my inclination was to just have a comma separate list of middle-ware to run in order as part of the standard service config.
default to what is enabled in paste today.
if need provide a way to load extra middle-ware using https://opendev.org/openstack/stevedore the same
way we do plugins in the rest of openstack.
I personally haven't been bothered with the absence of configuration mechanism for some time since most of the services introduced the basic set of middlewares such as http_proxy_to_wsgi, cors and healthcheck. However if we completely drop the mechanism to inject additional middleware and define static list in each service, we should probably determine the strategy about a few middlewares which are partially or not used in OpenStack services. - Sizelimit from oslo.middleware and Audit from keystonemiddleware are not globally used but only some include these in their pipeline - RequestNotifier from oslo.messaging and BasicAuth from oslo.middleware are not included by any default pipeline definition In the past I expected some users (especially cloud providers) might implement their own middleware for especially billing but I have no actual knowledge about actual use case.
Cheers, Stephen
PS: This topic came up about 18 months ago [6], but we don't appear to have reached a conclusion. Thus my bringing it up again.
[1] https://review.opendev.org/c/openstack/oslo.service/+/954055
I'm glad you spotted this as yes only the eventlet web-sever part was intended to be deprecated.
[2] https://pypi.org/project/Paste/#history [3] https://pypi.org/project/PasteDeploy/#history [4] https://pypi.org/project/Routes/#history [5] https://pypi.org/project/WebOb/#history [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack....
---
fwict, the following services all rely on this combo to build their own frameworks, with Nova most likely the progenitor in each case (I'm guessing)
* Nova * Barbican * Cinder * Designate * Freezer * Glance * Heat * Manila * Monasca * Neutron * Swift * Trove * Vitrage * Watcher
To extend the list, Aodh uses PasteDeploy but with pecan, and Masakari uses paste+pastedeploy (althoug these are not in requirements !!!)
The following services do *not* use these libraries:
* Cyborg (pecan) * Ironic (pecan) * Keystone (Flask + Flask-RESTful, with some webob) * Magnum (pecan) * Masakari (homegrown framework using webob) * Zaqar (falcon) * Zun (Flask)
... and Octavia may be added to this list, with pecan used.
participants (3)
-
Sean Mooney
-
Stephen Finucane
-
Takashi Kajinami