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.org/thread/5RQGZZMCKKHAVH4OLSJCLBQNIHYDPGZD/
>> [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
>>
>