On Thu, 2025-05-08 at 13:47 +0000, Dmitry Tantsur wrote:
Hi,
Thank you for highlighting this problem. Would it be possible for each affected project to provide (at least temporary) manual WSGI scripts?
We _could_ but that's a lot of duplicated work that will have to be reverted pretty soon after. I think this would be better done in the deployment projects themselves (since there are fewer of them than there are services). They can also do as Sean suggests and point to the module directly instead of the wsgi script. The only hold up I forsee in projects doing this themselves is that not all service projects currently have a '$service.wsgi' module as suggested in the community goal meaning their 'application' object could exist in a variety of places. In addition, it will move to e.g. 'service.wsgi.api' once in the near future. A 'try-except ImportError' conditional will handle this switch for us though. I'm happy to draft a prototype if the OSA and Kolla people can point me to the relevant places (@Dmitriy?). Stephen
(I can try to look into the Ironic side of things)
Dmitry
On 5/8/25 1:28 PM, Stephen Finucane wrote:
o/
As I noted nearly 18 months ago [1], changes in the Python packaging ecosystem are forcing our hand with regards to the necessity of to both add 'pyproject.toml' files and remove support for pbr's 'wsgi_scripts' entrypoint feature.
I was out last week and the week prior, but it seems there's been been a burst of activity around both areas owning to some setuptools issues. This is great to see, and the latter in particular will finally fulfil a community goal that was approved over a year ago [2]. Unfortunately, as a result of the delay in service projects addressing this goal, it seems likely (IMO) that we're not going to be able to wait two release cycles (until H, for projects only adding these modules now in F) to drop the wsgi scripts. This is because the setuptools maintainers understandably have little interest in maintaining the easy_install APIs that we had been relying on to date as public APIs, which means it's very likely that this feature will break in pbr sooner rather than later.
This being the case, I'd like to suggest that we rip the band aid off, and proceed with both adding new '$service.wsgi' modules and removing the old '$service-wsgi' scripts in the *same release*. To some degree, this ship has already sailed and at least Designate and Octavia have already done this [3][4] (and others like Magnum are planning to do so [5]) but I'd like to at least let deployment tooling folks know that this will be happening en masse. (It would also be nice to be able to plough on and close this effort off in the likes of Nova and Placement, rather than waiting as Sean Mooney is suggesting [6][7] :).)
Please let me know if anyone has any concerns. If not, I'll take silence as tacit agreement and (a) keep pursuing this approach in other services that are currently broken (like Masakari [8]) and (b) poke Sean with increasingly sharp sticks until they approve those Nova and Placement patches.
Cheers, Stephen
[1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [2] https://review.opendev.org/c/openstack/governance/+/902807 [3] https://review.opendev.org/c/openstack/designate/+/902846 [4] https://review.opendev.org/c/openstack/octavia/+/902812 [5] https://review.opendev.org/c/openstack/magnum/+/949110 [6] https://review.opendev.org/c/openstack/nova/+/902688 [7] https://review.opendev.org/c/openstack/placement/+/919582 [8] https://review.opendev.org/c/openstack/masakari/+/949154