17:00:32 <gouthamr> #startmeeting tc
17:00:32 <opendevmeet> Meeting started Tue Jun 24 17:00:32 2025 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:32 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:32 <opendevmeet> The meeting name has been set to 'tc'
17:00:39 <gouthamr> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct.
17:00:55 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
17:01:05 <gouthamr> #topic Roll Call
17:01:06 <noonedeadpunk> o/
17:01:53 <gmaan> o/
17:01:58 <cardoe> \o
17:02:18 <frickler> \o
17:02:51 <gouthamr> noted absence: b a u z a s,  g t e m a
17:03:09 <spotz[m]> o/
17:03:10 <mnasiadka> o/
17:03:38 <gouthamr> welcome everyone! lets get started
17:03:43 <gouthamr> #topic Last Week's AIs
17:04:07 <gouthamr> we took a couple of AIs last week to follow up on project inactivity and eventlet timelines
17:04:28 <gouthamr> 1) gmaan proposed a patch to mark cyborg "inactive"
17:04:50 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/952798 (Mark Cyborg inactive)
17:05:01 <gmaan> all good on this, PTL merged the ci fixes and other changes
17:05:22 <gmaan> that solve my concern at least for this cycle
17:05:58 <gmaan> as discussed in last week on IRC,  I abandon the change for now. and we will get more clarity about future maintenance in coming cycle election
17:06:04 <gouthamr> ack, we're still on a "sticky wicket" (heh, cricket reference) on cyborg's maintenance
17:06:09 <gmaan> that will be good checkpoint to re-iterate on this
17:06:15 <gmaan> yeah
17:06:24 <gmaan> we need to keep eyes on it
17:06:58 <gouthamr> ack, having no idea about how this works, can this project be considered mature or feature complete?
17:07:35 <gmaan> its hard to say feature complete as there are always more uses comes
17:08:09 <gouthamr> yeah, i ask because a core reviewer team may need to be onboarded if someone does show interest and if the existing core maintainers do end up leaving
17:08:15 <gmaan> but I have not investigated its maturity  especially how much test coverage it has. Nova do run cyborg tempest job but as non voting
17:08:22 <fungi> in this case it at least still needs testing kept working, support for newer versions of dependencies, someone to fix security vulnerabilities when they're identified...
17:08:32 <gouthamr> and migrate off of eventlet
17:08:41 <gmaan> yeah ^^ this one
17:08:51 <noonedeadpunk> it depends a lot on nova as well
17:09:03 <gmaan> yeah
17:09:06 <noonedeadpunk> so any major change in nova would require project to adopt
17:09:14 <fungi> eventlet now, but in the future whatever openstack-wide changes are identified too
17:09:35 <gmaan> in Nova, we keep it in backward compatible way but yes it needs to adopt new changes if there is any
17:10:02 <noonedeadpunk> well, they'd need to explicittly use other microapi version at least
17:10:04 <fungi> is cyborg exempt from rbac work? privsep improvement, etc...
17:10:14 <noonedeadpunk> I don't think they are?
17:10:38 <fungi> so there are plenty of examples of why continued development is needed, and the project couldn't just be "feature complete"
17:10:45 <noonedeadpunk> ++
17:10:54 <gouthamr> #link https://opendev.org/openstack/cyborg/src/branch/master/releasenotes/notes/implement_oslo_privsep-4fc6e15360c92772.yaml
17:10:57 <cardoe> well the project can be feature complete but maintenance is still required
17:10:58 <gmaan> rbac work is done for cyborg
17:11:03 <gouthamr> ^ they've completed privsep stuff
17:11:09 <gouthamr> nice
17:11:35 <gmaan> it is in much better place than many other project where RBAC and other work is not yet started :)
17:11:58 <fungi> fair point, perhaps "feature complete" at most sends a message to potential contributors that the project won't review their feature addition changes
17:12:42 <fungi> though "complete" seems final, whereas if enough people appeared to take it beyond mere maintenance in the future it might suddenly be considered feature-incomplete again
17:14:09 <gmaan> anyways, that is all from me on this.
17:15:15 <fungi> "maintenance mode" is a term other projects outside openstack have used for this state, which seems more accurate
17:15:49 <gouthamr> ack, ty.. the next AI was to propose an update to the eventlet goal
17:15:57 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/952903 (Make Eventlet removal deadlines more acceptable for operators)
17:16:07 <gouthamr> ^ there's a good deal of discussion happening on this proposal
17:16:43 <gouthamr> anything to discuss about this here?
17:18:15 <gouthamr> the important agreement i see here is that we don't _require_ eventlet support in python 3.13
17:18:28 <gouthamr> too much to unpack there
17:18:58 <gouthamr> but, if you deploy with python3.13, you'll need to use openstack services in a threaded mode (or whatever the services chose to replace eventlet with)
17:20:27 <gouthamr> does that align with your understanding as well?
17:20:27 <gouthamr> python3.12 will be around for a while, and one can continue using eventlet if the service supports it even with 2026.2
17:21:16 <gouthamr> that's not to say services need to support eventlet until then, there may be some (neutron, ironic etc) that will not rely on eventlet during that release, or even prior releases
17:21:25 <fungi> it sounds like the debian maintainers are planning to release openstack for python 3.12 and then hope that eventlet gets a fix so it can be backported
17:21:36 <fungi> er, for python 3.13 i mean
17:21:43 <gouthamr> i see
17:22:02 <fungi> the upcoming debian trixie release in about a month or so will only have python 3.13
17:22:15 <fungi> and openstack is being included, just probably in a broken condition
17:22:34 <fungi> until (if ever) eventlet is patched to work on 3.13
17:22:50 <frickler> iiuc the latest news was that there is a bug in cpython proper affecting nova on py3.13
17:24:10 <gouthamr> ah, so we have bigger/different problems too
17:24:30 <frickler> #link https://github.com/python/cpython/issues/135552
17:24:37 <gouthamr> ty
17:24:39 <gouthamr> alright that's all the AIs i recall, was anyone else working on anything else
17:24:39 <mnasiadka> Well, 2025.2 is not SLURP, so let's hope not many people are going to go the Trixie+OpenStack route
17:25:27 <fungi> no, they're shipping openstack 2025.1 (slurp), 2025.2 won't be available in time for trixie
17:25:48 <fungi> so it's openstack 2025.1 with python 3.13
17:26:02 <fungi> (plus whatever future patches fix it into a working condition)
17:26:14 <bauzas> (can't really comment, just reading)
17:26:24 <gmaan> 2025.1 does not support py3.13 so there might be more issues?
17:26:26 <gouthamr> that wasn't even on our runtime :(  they'll have a hard time with the backports i suppose
17:26:32 <gmaan> yeah
17:26:54 <fungi> yeah, the distro doesn't take that into account when deciding what version of python it's going to include
17:27:24 <gouthamr> for sure
17:27:25 <bauzas> but honestly, the main concern I had for creating this patch was about the fact it would be not way to have all the possibility by 2026.1
17:27:53 <gmaan> fair enough but I think we should go as per our plan. I commented in eventlet deadline proposal about we can support py3.12 longer if project needs more time for eventlet-removal
17:27:57 <gmaan> that is also fair
17:28:17 <gouthamr> yeah, lets please continue the discussion on gerrit
17:28:48 <gouthamr> #topic Updating inactive projects
17:28:58 <gmaan> bauzas: I think if you update your proposal with what Sean mentioned (oslo remove eventlet in 2027.2 instead of 2028.1), it should be more clear feedback?
17:29:34 <gouthamr> M-2 is in a couple of weeks, was wondering if anything had to be discussed wrt inactive projects?
17:30:00 <gouthamr> my bad
17:30:03 <gouthamr> its next week
17:30:10 <bauzas> gmann: I'll try
17:30:42 <gmaan> thanks. no hurry.
17:32:18 <gouthamr> sounds like no.. lets move on
17:32:30 <gouthamr> #topic setuptools and pbr
17:33:22 <gouthamr> we were chatting on #opendev a few days ago about a deadline wrt setuptools supporting something pbr has relied on
17:33:54 <cardoe> what specifically?
17:33:59 <clarkb> specifically the ScriptWriter tooling to write out entrypoint scripts for command line tools and the wsgi scripts
17:34:04 <fungi> setuptools wants to remove pkg_resources later this year
17:34:15 <clarkb> fungi: thats the toehr thing
17:34:20 <gouthamr> i don't have much context about this, but i asked stephenfin if he could join us / help understand what we need to do/be prepared for
17:34:34 <clarkb> ScriptWriter was part of vendored easy_install which is getting completely removed
17:35:08 <clarkb> they moved ScriptWriter into a private code path in setuptools. Pbr writes its own scripts because setuptools by default uses pkg_resources or importlib if available which are both very slow compared to a simple import
17:35:46 <clarkb> then separately setuptools is planning to remove pkg_resources as well so PBR will need to default to importlib and fallback to pkg_resources for older compatibility
17:35:48 <fungi> #link https://bugs.launchpad.net/pbr/+bug/2107732 covers the scriptwriter case
17:36:49 <clarkb> for the ScriptWriter situation we could go back to using setuptools' slow scripts and just have pbr stop managing that stuff. Or write things directly without setuptools code. Or maybe use setuptools private code and hope it doesn't break
17:37:19 <clarkb> for both items I think there is a hard deadline of ~October 31 of having an updated PBR that works without the stuff that will be removed in setuptools
17:37:48 <gouthamr> #link https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/command/easy_install.py#L27 (deadline in setuptools)
17:38:04 <cardoe> So I think one of the things that needs to be understood is the underlying behavior. So today for example PBR is a runtime dependency for OpenStack projects just to load the version. It's similar in the Python world where setuptools was a runtime dependency and assumed to be everywhere but they're really shifting away from this mindset.
17:38:22 <cardoe> setuptools seems to be more becoming a library for other frontends to take over. Like the script stuff.
17:38:38 <cardoe> They're nudging people actively to hatch for example.
17:38:52 <clarkb> well the script stuff is explicitly made private with this change so I don't think they are trying to let other tools use that
17:39:10 <clarkb> and pkg_resources is going away because importlib replaces it
17:39:14 <fungi> well, pbr doesn't *need* to be used at runtime to get version information. i can provide examples using pkg_resources or importlib to access version metadata, including the special version metadata written by pbr
17:39:38 <cardoe> fungi: yes but projects want to remain consistent so they use that.
17:40:29 <fungi> also calling pkg_resources or importlib at runtime to get version metadata is exactly what pbr does anyway (and the runtime use already uses importlib instead of pkg_resources if it's available)
17:40:45 <cardoe> I've been -1'd on that change to drop the runtime depend on pbr.
17:40:51 <cardoe> But anyway, I've shifted away from the convo.
17:41:11 <fungi> yes, runtime pbr use is essentially unaffected here, it's dist build that's the problem
17:41:20 <cardoe> We rely on pbr to build packages and upstream is dropping stuff. So the question is, are we gonna vendor it or what's the other option?
17:41:51 <fungi> vendoring or fixing is probably equal amounts of work
17:42:01 <clarkb> cardoe: I listed the options above. Either we let setuptools write the scripts for us and accept their less efficient script startup costs. We do it ourselves (which might be vendoring). Or we use the code that is now private in setuptools
17:42:16 <fungi> in many cases, the "fix" is to just drop more code and now redundant features from pbr
17:42:22 <clarkb> then for pkg_resources we need to prefer importlib everywhere in pbr with a fallback to pkg_resources for old setuptools
17:42:49 <cardoe> My vote would be to lessen our maintenance burden by preferring the upstream path.
17:43:07 <fungi> i think there are quite a few places where we use pkg_resources for things right now that pbr no longer needs to do because setuptools gained equivalent features over the years
17:43:16 <cardoe> Otherwise we end up in the same boat as oslo stuff where its used by everyone but nobody really wants to use it.
17:43:50 <fungi> pbr *is* "oslo stuff" btw (it was originally named oslo.packaging when it was first extracted from openstack/common in nova)
17:43:53 <clarkb> note the less efficient startup cost is possibly measured in seconds for tools like osc on slow disks
17:43:53 <cardoe> We'll have another one when they get rid of setup.cfg support for pyproject.toml
17:44:56 <gouthamr> clarkb: that would be terrible for OSC plugins
17:44:56 <fungi> technically pbr is providing backward compatibility for setup.cfg things that get dropped from setuptools, as setup.cfg was in pbr before setuptools supported it (a feature inherited from distutils and distutils2)
17:45:32 <clarkb> I suppose another option is to work with upstream to fix their slow scripts then adopt them
17:45:44 <fungi> pbr already translates old distutils setup.cfg directives to setuptools-recognized metadata today
17:45:47 <cardoe> So got an example of what gets generated?
17:46:49 <clarkb> https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L332-L395
17:47:34 <clarkb> vs https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/_scripts.py#L125-L160
17:47:51 <cardoe> So 386 to 395 is roughly how all my python stuff looks even without pbr
17:48:26 <clarkb> because you're installing the package you know you can import it directly. This means you don't need pkg_resources/importlib. I do not know why setuptools uses importlib/pkg_resources given this fact of package installation
17:48:47 <clarkb> but it can introduce significant slowness depending on the speed of your disks and how many packages are in python path
17:49:30 <clarkb> anyway we don't have to solve this here. I think the idea was to raise awareness that pbr will break on october 31 unless something is done
17:49:38 <gouthamr> +1
17:49:54 <gouthamr> the handful of oslo folks are busy with eventlet atm
17:50:03 <clarkb> one issue is that pkg_resources is going away. The other is that setuptools will break our ability to use their script writing facilities to replace the scritps setuptools would write with something more efficient
17:51:44 <gouthamr> thanks for summarizing this
17:52:39 <gouthamr> as next steps, we're looking for an assignee to tackle this in pbr
17:53:14 <gouthamr> Oct 31st is past the Flamingo release date
17:54:08 <gouthamr> will we be able to workaround and keep this situation from breaking CI while we work on the fix?
17:54:26 <gouthamr> (if it comes to that)
17:54:42 <clarkb> https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/_scripts.py#L213-L222 this seems to be the primary bit of code we're relying on from ScriptWriter
17:54:57 <clarkb> writing our own version is probably doable if someone wants to dive into that
17:55:21 <fungi> any workarounds would be trying to pin to older setuptools, e.g. by preinstalling in venvs or with version limits in pyproject.toml files in each project
17:55:44 <fungi> and may not be 100% viable
17:55:49 <gouthamr> yeah
17:56:30 <frickler> one other thing to note is that pbr CI is very broken currently. that also needs fixing before any real fixes can be applied
17:56:48 <gouthamr> lets raise this through openstack-discuss, and also check with #openstack-oslo folks if anyone planned to look at this
17:56:56 <gouthamr> frickler: ack
17:57:12 <gouthamr> we have ~3 mins
17:57:27 <gouthamr> the rest were regular topics
17:57:43 <gouthamr> so i'll skip past these and lets take the remaining time for
17:57:48 <gouthamr> #topic Open Discussion
17:58:57 <spotz[m]> While FOrums are open in the CFP, do we want to submit a meetup?
17:59:16 <clarkb> spotz[m]: when do forum session propsals close?
17:59:29 <spotz[m]> Let me look
17:59:55 <noonedeadpunk> I think it was smth 9th of July
18:00:08 <fungi> so that's two weeks out if so
18:00:30 <noonedeadpunk> 8 July  23:59 PT, sorry (techynically 9 for me :D)
18:00:37 <spotz[m]> Yeah we don't have a date, we do say we'll notify in July. Main CFP I believe will be notified tomorrow
18:00:54 <gouthamr> Closes 8 July at 23:59 PST
18:00:58 <gouthamr> #link https://summit2025.openinfra.org/cfp/
18:01:07 <gouthamr> ^ ah, spotz[m] knows better
18:01:09 <noonedeadpunk> and that was in email as well
18:01:21 <gouthamr> :D i mean she's the program committee chair
18:01:25 <spotz[m]> Had to log out and in from the tool - Accepting submissions until July 09, 2025 1:59 am America/Chicago
18:01:54 <spotz[m]> I'll talk to Helena about adding it to the Summit page
18:02:01 <gouthamr> it's on the page
18:02:32 <gouthamr> okay, lets wrap it up
18:02:36 <gouthamr> thank you all for attending
18:02:56 <gouthamr> next week's meeting will be held simultaneously on meetpad and IRC
18:03:04 <spotz[m]> Thanks all
18:03:09 <spotz[m]> And I don't see it on - https://summit2025.openinfra.org/
18:03:30 <gouthamr> #endmeeting