On 08/05/2025 14:47, 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?
(I can try to look into the Ironic side of things)
i think nova/placement did this for a while. i also dont thikn its strictly requried. basiclaly the module iself shoudl be useabel as a wsgi script just update to <path to python <sitepackates>/<service>/wsgi/<entrypoint> i.e. /usr/lib/python3/dist-packages/watcher/wsgi/api.py but beyond that i also think you can just replace ``` console_scripts = keystone-manage = keystone.cmd.manage:main keystone-status = keystone.cmd.status:main wsgi_scripts = keystone-wsgi-admin = keystone.server.wsgi:initialize_admin_application keystone-wsgi-public = keystone.server.wsgi:initialize_public_application ``` ``` console_scripts = keystone-manage = keystone.cmd.manage:main keystone-status = keystone.cmd.status:main keystone-wsgi-admin = keystone.server.wsgi:initialize_admin_application keystone-wsgi-public = keystone.server.wsgi:initialize_public_application ``` and then it would "just work" as before as that will create a keystone-wsgi-public script in /usr/bin/keystone-wsgi-public that just uses the wsgi module i have not tested that but that would make it entrily transparent assume that works. if we can confirm that works that is actully how i would recommend deleteing the wsgi_scripts entryp point form setup.cfg
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