On 04/11/2025 01:25, Tony Breeds wrote:

Hi Stephen,

...

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: In general I feel like this makes sense. At the risk of "bike shedding" can we use oslo_wsgi. Namespaced packages continue to be a problem. I concede that this may only be a problem with older releases, maybe all

On Tue, 4 Nov 2025 at 03:40, Stephen Finucane <stephenfin@redhat.com> wrote: the tools now correctly and completely canonicalise the package name but maybe not?

I understand that this would be a departure from the norm in oslo. Thoughts? i would personally perfer consitency with rest of oslo and use oslo.wsgi but i dont really have a strong feeling one way or another

so im fine with whatever the oslo core team deciede. slight prefereence but not a blocker for me either way long term im not sure we shoudl neet to maintain this package but i agree that it makes sense to put it under oslo as i dont think maitianing this lib for non openstack usecase should be an end goal.

Yours Tony.

+1 for the name consistency by using a period. Le mar. 4 nov. 2025 à 12:24, Stephen Finucane <stephenfin@redhat.com> a écrit :

On Tue, 2025-11-04 at 12:25 +1100, Tony Breeds wrote:

...

Hi Stephen,

On Tue, 4 Nov 2025 at 03:40, Stephen Finucane <stephenfin@redhat.com> 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:

In general I feel like this makes sense. At the risk of "bike shedding" can we use oslo_wsgi. Namespaced packages continue to be a problem. I concede that this may only be a problem with older releases, maybe all the tools now correctly and completely canonicalise the package name but maybe not?

I understand that this would be a departure from the norm in oslo. Thoughts?

We haven't used namespaced packages in oslo for a long time now [1]. I assume you're referring to the use of periods in package names, and the issues this has caused in the recent past due to changes in our release tooling [2]. It's a fair point but that only affected pkg_resources, which has been replaced by packaging and importlib.metadata and isn't long for the world [3][4], and only on Python <= 3.8 (due to missing fixes). I think there should be no issues going forward in staying consistent in our package naming here.

Similarly, there are other changes we could make when bootstrapping a new project, such as switching to a src layout [5], but I've intentionally avoided making these on the assumption that such changes should be done for all (oslo) projects or none. I am going fully typed and ruff formatted from the get-go though...

Cheers, Stephen

[1] https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-p... [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [3] https://setuptools.pypa.io/en/latest/pkg_resources.html [4] https://review.opendev.org/q/topic:%22pkg_resources-removal%22 [5] https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout...

...

Yours Tony.

-- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

On Tue, 4 Nov 2025 at 22:24, Stephen Finucane <stephenfin@redhat.com> wrote:

We haven't used namespaced packages in oslo for a long time now [1]. I assume you're referring to the use of periods in package names, and the issues this has caused in the recent past due to changes in our release tooling [2].

Indeed I meant packages with '.' in the name that look like namespaced packages. If you're confident that the '.' vs '_' isn't going to be a problem then following the norm is indeed better. Tony.

@Takashi: From a pure release management perspective, if we want to prefix it as an oslo library, then, I think we have to stick to the coordinated releases cadence, and so having stable branches, but, I don't think this is a problem to have an unstable deliverable during few series (e.g oslo.metrics was introduced few cycles ago and it is still in unstable API mode in terms of semver). https://opendev.org/openstack/releases/src/commit/a6af75e9e97e449c9a7f619d1c... In terms of backports, if I understand it correctly, oslo.wsgi will be more the less the result of existing code (oslo.service's wsgi routing pieces, and some OpenAPI things already done elsewhere in OpenStack), so the code should be stable enough from the beginning. Thoughts? Le mar. 4 nov. 2025 à 15:10, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :

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

-- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

On Mon, 2025-11-10 at 14:03 +0100, Thomas Goirand wrote:

On 11/3/25 5:39 PM, 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

Hi Stephen,

Over the years, I found it very annoying that in OpenStack, there was no standard ways to write an API server, with all projects using a different framework. For example: - flask (keystone, cloudkitty, designate, octavia...) - paste (nova, neutron, swift...) - falcon (barbican, zaqar...)

I found it then hard to deal with, and it is also annoying to have to learn them all.

If oslo.wsgi can help having a unified framework, and if we don't fall into the unified standard trap: https://xkcd.com/927/

then it's a good thing! I'd love it if it became a TC goal to have all services switch to some kind of unified API framework.

This isn't the goal of the project. I touched on this with this statement:

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.

The goal here is purely to gather common code currently duplicated across multiple projects into a single location, though ideally in a way hides as much of the internal library usage as possible (more on this below).

However, I see you requirements.txt having:

Paste>=2.0.2 # MIT PasteDeploy>=1.5.0 # MIT Routes>=2.3.1 # MIT WebOb>=1.7.1 # MIT

Why doing that? Why not choosing for example Flask or fast-api? Is this because you're trying to do that for Nova at first?

That requirements.txt file is only there because we didn't have an easy way to validate extras in the requirements-check job. I've now fixed this, so I expect to move much of this into separate extras.

I once wrote my own service myself, I found that flask was nice because I only needed to write a decorator for selecting the route. Example:

@app.route('/healthcheck', methods=['GET']) def health_check(): return jsonify({'status': 'ok', 'service': 'foo'}), 200

and also managed to do the same for the policy. Example:

@policy_checker('foo:add') def add_bar(): ....

Is this something that oslo.wsgi will provide without its users having to reinvent such wheel?

Not initially, no. Anything derived or based on Nova is wedded to the routes + paste.deploy + webob model for now and (at least initially) we are stuck with those. Use of a common oslo.wsgi Router class that hides its usage of Routes *would* allow us to swap out Routes in the future, however, I don't see us ever moving to a decorator approach for routing rather than the hardcoded mapping of URLs to controllers. Given my recent experience with the OpenAPI efforts there, such an effort would require a a huge amount of rework for projects like Nova and provide limited (and questionable) value.

Also, is there any doc on how to write a new service using oslo.wsgi? It'd be great to have a quick example like a foo/api.py so it'd be easy to start with it.

I don't know how much sense this would make. I would expect this project to be a holding place for code that is commonly shared across projects. At some point we might have people using it to bootstrap a new project, but it seems more likely that people would be using it to replace their existing in-tree version of e.g. a Router with a common one from oslo.wsgi. Hope this clarifies things, Stephen

Thanks a lot for this initiative, Cheers,

Thomas Goirand (zigo)