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.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
>