Hi Stephen, Thanks for proposing it and I agree with the addition of the library as well as its naming. This probably allows us to get rid of paste/PasteDeploy more easily and also provide us more chance to standardize the software stack to build WSGI server. I'm also wondering this may lead us to merging oslo.middelware into oslo.wsgi at some point (given the fact that these two are both WSGI server related) though I think keeping these two separate does not really harm. One small question is the release model of this library. In my opinion we should avoid branchless model until the library is fully stabilized (for example until the library is released and is adopted in a few of OpenStack services), because I expect we may more often face need of backporting bug fixes during its early phase. However I'd like to hear your thoughts just in case you have any plan. Thank you, Takashi On 11/4/25 1:39 AM, Stephen Finucane wrote:
o/
I'd like to propose the creation of a new "oslo.wsgi" project that service projects should adopt, where it makes sense to. My reasons for this proposal are three-fold:
* As we've been working on the OpenAPI work for various services, we've found ourselves copy-pasting a lot of the code between these services. This has occasionally led to issues when those copies are incomplete [1][2]. Historically speaking, copy-pasting of code between services is a sure sign that this code should be generalised and placed in an oslo library * I have previously noted [3] that oslo.service contains some non- eventlet-related WSGI routing code, and there are questions around whether (a) that code should have been placed there in the first place and (b) how we can maintain that long-term once the eventlet code is removed (the 'oslo_service.wsgi' module has side effects since it imports the backend configuration stuff). * I have also raised some concerns around our use of paste.deploy and routes [1], both of which are minimally maintained nowadays. Many oslo libraries are designed to abstract their underlying libraries, allowing users to switch between e.g. different messaging backends (oslo.messaging) or caching services (oslo.cache).
Taken together, I think now would be a good time to provide a new library. I have an initial prototype available [4] which is effectively just a refactoring of the code from oslo.service, but I expect to add both more functionality to this existing code from existing consumers (Nova, Manila, Cinder etc.) and to add the openapi validation machinery. I imagine longer-term, this should evolve to allow us to replace the underlying libraries. However, we should obviously not get into the business of writing our own web framework. I also don't think it would make sense for all services to adopt all aspects of this project, since not all projects have any OpenAPI efforts ongoing at the moment and not all of them use the pastedeploy-routes-webob combo.
Given the above rationale and caveats, what do people think? Are there any objections to this idea? Please let me know. If there is not, I will go figure out how to get the ball rolling on this.
Cheers, Stephen
PS: Why oslo.wsgi instead of a more generic name like debtcollector or futurist? I don't think this library will be useful outside of OpenStack, so the oslo prefix makes sense.
[1] https://review.opendev.org/c/openstack/ironic/+/963938 [2] https://review.opendev.org/c/openstack/ironic/+/960291 [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [4] https://github.com/stephenfin/oslo.wsgi