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