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.org/message/KK56O32VOJDMT5WTG5QANHYRYNGIELOG/
> [4] https://github.com/stephenfin/oslo.wsgi
>