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