i mean i said in my review i wanted to merge them at milestone 2 to give installer time to update

So, this is one of the big problems I see. As deployment tools are having a trailing release model, ie OpenStack-Ansible will just release Epoxy by milestone 2. Also, dropping the wsgi script at the same time as adding the module, will guarantee in completely nuked CI jobs, as there will be no point in time, when we can run integrated tests which will be passing. So it sounds like we should add noop jobs instead to be able to perform the switch. So at the very least, adding the WSGI module must be implemented before the console script is removed. They can be 2 patches in the same chain, but there should be at least some point in time where both things work. чт, 8 мая 2025 г. в 15:19, Sean Mooney <smooney@redhat.com>:

On 08/05/2025 12:28, 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.

i mention this on irc before that merged that i thought that was incorrect i even considered proposing a revert for designate when i saw it was merged because it broke our upgrade policy since as far as im aware there was no deprecation notice in epoxy for the wsgi_script.

i didn't propose a revert

given it trivial to do this fix without deleting them i think we agree the correct approach is 2 patches.

1 to add the support for the new wsgi module and add pyproject.toml and then a second one to drop the wsgi_script extension usage.

the first pache should be back-ported ot epoxy the second could be merged this cycle if we really wanted or needed too but if thats the plan we also need to have a deprecation release note back-ported to expoy if we want to follow the spirit of SLURP policy even if its strictly not following the policy rules as written.

Rules as written we are not intended to backprot depredations retroactively nor should we ever remove functionality unless it has been deprecated in the prior skip level upgrade release i.e. 2025.1

...

(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] :).)

im mostly suggesting waiting to next cycle to delete them and back-porting the deprecation 2025.1 for project that didn't already support this in epoxy

the removal in nova/placement i suggested waiting to m2 to allow the installer project to update if they still us mod_wsgi. i reached out to kolla and they have apparently started swapping to uwsgi this? or last cycle so they should be ok and OSA already did that change too. im perfectly

happy to upgrade to +2 on both of those removals this cycle i just wanted to notify folks of the planned change on the mailing list first which this mail does.

going back to the approach for project that don't have support for this on 2025.1 today.

the pyproject.toml and wsgi module should be back port to epoxy so that its available for those upgrading form 2025.1 to 2026.1 and so that grenade works. you can technically modify your grenade plugin to reconfigure the uwsgi server to work around this but none of the exiting service do this.

so as far as i am aware there is no example code to follow for project and someone would have to spend time figuring this our or we can just back-port a entrily backward compatible low risk patch which is way less work and the better solution IMO.

...

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.

i mean i said in my review i wanted to merge them at milestone 2 to give installer time to update but since then i confirmed kolla now uses uwsgi.

it will break our new third party ci job when they trigger on master if we drop them but we can very likely fix that in a week or so. we just need a little time to go do that.

little is important because i don't think we should let this drag on which is why i was suggesting m2 which

i belvie i july 3rd ish

that give folks basically 2 months to make sure they update there ci jobs/installer to continue to work.

...

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

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

On Thu, May 8, 2025, at 7:22 AM, Dmitriy Rabotyagov wrote:

I'm pretty sure it is.

There is no point in the Git tree, where we can say - ok, now use a module. As either it will be broken before the switch, or with it. Actually it is not required, but only if it's the single project doing such migration. As in case there're 2 of them, it will cause circular dependency right away for the integration test.

So the way to make all play nicely, is to use SHA/versions where both modules and scripts are present, switch over, profit.

And as you said - switching to using modules is a no brainer, it is a trivial patch in fact for deployment. But only if there is a way to not have to nucke CI in between.

If uwsgi has the ability to directly call the application factory method (init_application() in [1]) then you should be able to start doing that without any changes to designate. That said I have found documentation for gunicorn and granian indicating this is possible, but have not been able to find an indication that uwsgi can do this. If this isn't possible, then I agree we probably need to keep the old and new systems in place for some amount of time to make the transition simpler.

[1] https://review.opendev.org/c/openstack/designate/+/902846