Tuesday, 2025-06-24

bauzasgouthamr: I'm afraid I'll barely be able to discuss today at the TC meetign15:55
bauzasgouthamr: I'll be in some place where I can read the discussions but I won't really be able to interact15:55
gouthamrack bauzas thanks for letting me know15:58
gouthamrtc-members: a gentle reminder that our weekly IRC meeting will be hosted here in ~59 minutes16:01
gouthamrthere’s a foundation board discussion on AI Contribution policy kicking off right now - I’m unable to join… if anyone here is interested:16:02
gouthamrhttps://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.org/thread/46X62IF7FIHHJTO4ICMLFDJOIKLSU25L/16:02
gtemagouthamr: I can't join today, have an appointment 16:04
gouthamrack gtema16:05
fricklerzoom ... great16:10
gouthamrhaha, we have AI taking notes there 😄16:11
spotz[m]Thanks it wasn't on my calendar!16:16
gouthamr#startmeeting tc17:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
opendevmeetThe meeting name has been set to 'tc'17:00
gouthamrWelcome 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
gouthamrToday's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting17:00
gouthamr#topic Roll Call17:01
noonedeadpunko/17:01
gmaano/17:01
cardoe\o17:01
frickler\o17:02
gouthamrnoted absence: b a u z a s,  g t e m a17:02
spotz[m]o/17:03
mnasiadkao/17:03
gouthamrwelcome everyone! lets get started17:03
gouthamr#topic Last Week's AIs17:03
gouthamrwe took a couple of AIs last week to follow up on project inactivity and eventlet timelines17:04
gouthamr1) gmaan proposed a patch to mark cyborg "inactive" 17:04
gouthamr#link https://review.opendev.org/c/openstack/governance/+/952798 (Mark Cyborg inactive)17:04
gmaanall good on this, PTL merged the ci fixes and other changes17:05
gmaanthat solve my concern at least for this cycle17:05
gmaanas discussed in last week on IRC,  I abandon the change for now. and we will get more clarity about future maintenance in coming cycle election17:05
gouthamrack, we're still on a "sticky wicket" (heh, cricket reference) on cyborg's maintenance 17:06
gmaanthat will be good checkpoint to re-iterate on this17:06
gmaanyeah17:06
gmaanwe need to keep eyes on it 17:06
gouthamrack, having no idea about how this works, can this project be considered mature or feature complete?17:06
gmaanits hard to say feature complete as there are always more uses comes17:07
gouthamryeah, 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
gmaanbut I have not investigated its maturity  especially how much test coverage it has. Nova do run cyborg tempest job but as non voting17:08
fungiin 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
gouthamrand migrate off of eventlet17:08
gmaanyeah ^^ this one17:08
noonedeadpunkit depends a lot on nova as well17:08
gmaanyeah17:09
noonedeadpunkso any major change in nova would require project to adopt17:09
fungieventlet now, but in the future whatever openstack-wide changes are identified too17:09
gmaanin Nova, we keep it in backward compatible way but yes it needs to adopt new changes if there is any17:09
noonedeadpunkwell, they'd need to explicittly use other microapi version at least17:10
fungiis cyborg exempt from rbac work? privsep improvement, etc...17:10
noonedeadpunkI don't think they are?17:10
fungiso there are plenty of examples of why continued development is needed, and the project couldn't just be "feature complete"17:10
noonedeadpunk++17:10
gouthamr#link https://opendev.org/openstack/cyborg/src/branch/master/releasenotes/notes/implement_oslo_privsep-4fc6e15360c92772.yaml 17:10
cardoewell the project can be feature complete but maintenance is still required17:10
gmaanrbac work is done for cyborg17:10
gouthamr^ they've completed privsep stuff17:11
gouthamrnice17:11
gmaanit is in much better place than many other project where RBAC and other work is not yet started :)17:11
fungifair point, perhaps "feature complete" at most sends a message to potential contributors that the project won't review their feature addition changes17:11
fungithough "complete" seems final, whereas if enough people appeared to take it beyond mere maintenance in the future it might suddenly be considered feature-incomplete again17:12
gmaananyways, that is all from me on this.17:14
fungi"maintenance mode" is a term other projects outside openstack have used for this state, which seems more accurate17:15
gouthamrack, ty.. the next AI was to propose an update to the eventlet goal17:15
gouthamr#link https://review.opendev.org/c/openstack/governance/+/952903 (Make Eventlet removal deadlines more acceptable for operators) 17:15
gouthamr^ there's a good deal of discussion happening on this proposal17:16
gouthamranything to discuss about this here?17:16
gouthamrthe important agreement i see here is that we don't _require_ eventlet support in python 3.13 17:18
gouthamrtoo much to unpack there17:18
gouthamrbut, 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:18
gouthamrdoes that align with your understanding as well? 17:20
gouthamrpython3.12 will be around for a while, and one can continue using eventlet if the service supports it even with 2026.2 17:20
gouthamrthat'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 releases17:21
fungiit 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 backported17:21
fungier, for python 3.13 i mean17:21
gouthamri see17:21
fungithe upcoming debian trixie release in about a month or so will only have python 3.1317:22
fungiand openstack is being included, just probably in a broken condition17:22
fungiuntil (if ever) eventlet is patched to work on 3.1317:22
frickleriiuc the latest news was that there is a bug in cpython proper affecting nova on py3.1317:22
gouthamrah, so we have bigger/different problems too17:24
frickler#link https://github.com/python/cpython/issues/13555217:24
gouthamrty17:24
gouthamralright that's all the AIs i recall, was anyone else working on anything else17:24
mnasiadkaWell, 2025.2 is not SLURP, so let's hope not many people are going to go the Trixie+OpenStack route17:24
fungino, they're shipping openstack 2025.1 (slurp), 2025.2 won't be available in time for trixie17:25
fungiso it's openstack 2025.1 with python 3.1317:25
fungi(plus whatever future patches fix it into a working condition)17:26
bauzas(can't really comment, just reading)17:26
gmaan2025.1 does not support py3.13 so there might be more issues?17:26
gouthamrthat wasn't even on our runtime :(  they'll have a hard time with the backports i suppose17:26
gmaanyeah17:26
fungiyeah, the distro doesn't take that into account when deciding what version of python it's going to include17:26
gouthamrfor sure17:27
bauzasbut 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.117:27
gmaanfair 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-removal17:27
gmaanthat is also fair17:27
gouthamryeah, lets please continue the discussion on gerrit17:28
gouthamr#topic Updating inactive projects17:28
gmaanbauzas: 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:28
gouthamrM-2 is in a couple of weeks, was wondering if anything had to be discussed wrt inactive projects? 17:29
gouthamrmy bad17:30
gouthamrits next week17:30
bauzasgmann: I'll try 17:30
gmaanthanks. no hurry.17:30
gouthamrsounds like no.. lets move on17:32
gouthamr#topic setuptools and pbr 17:32
gouthamrwe were chatting on #opendev a few days ago about a deadline wrt setuptools supporting something pbr has relied on17:33
cardoewhat specifically?17:33
clarkbspecifically the ScriptWriter tooling to write out entrypoint scripts for command line tools and the wsgi scripts17:33
fungisetuptools wants to remove pkg_resources later this year17:34
clarkbfungi: thats the toehr thing17:34
gouthamri 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 for17:34
clarkbScriptWriter was part of vendored easy_install which is getting completely removed17:34
clarkbthey 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 import17:35
clarkbthen 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 compatibility17:35
fungi#link https://bugs.launchpad.net/pbr/+bug/2107732 covers the scriptwriter case17:35
clarkbfor 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 break17:36
clarkbfor 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 setuptools17:37
gouthamr#link https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/command/easy_install.py#L27 (deadline in setuptools)17:37
cardoeSo 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
cardoesetuptools seems to be more becoming a library for other frontends to take over. Like the script stuff.17:38
cardoeThey're nudging people actively to hatch for example.17:38
clarkbwell the script stuff is explicitly made private with this change so I don't think they are trying to let other tools use that17:38
clarkband pkg_resources is going away because importlib replaces it17:39
fungiwell, 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 pbr17:39
cardoefungi: yes but projects want to remain consistent so they use that.17:39
fungialso 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
cardoeI've been -1'd on that change to drop the runtime depend on pbr.17:40
cardoeBut anyway, I've shifted away from the convo.17:40
fungiyes, runtime pbr use is essentially unaffected here, it's dist build that's the problem17:41
cardoeWe 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
fungivendoring or fixing is probably equal amounts of work17:41
clarkbcardoe: 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 setuptools17:42
fungiin many cases, the "fix" is to just drop more code and now redundant features from pbr17:42
clarkbthen for pkg_resources we need to prefer importlib everywhere in pbr with a fallback to pkg_resources for old setuptools17:42
cardoeMy vote would be to lessen our maintenance burden by preferring the upstream path.17:42
fungii 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 years17:43
cardoeOtherwise we end up in the same boat as oslo stuff where its used by everyone but nobody really wants to use it.17:43
fungipbr *is* "oslo stuff" btw (it was originally named oslo.packaging when it was first extracted from openstack/common in nova)17:43
clarkbnote the less efficient startup cost is possibly measured in seconds for tools like osc on slow disks17:43
cardoeWe'll have another one when they get rid of setup.cfg support for pyproject.toml17:43
gouthamrclarkb: that would be terrible for OSC plugins17:44
fungitechnically 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:44
clarkbI suppose another option is to work with upstream to fix their slow scripts then adopt them17:45
fungipbr already translates old distutils setup.cfg directives to setuptools-recognized metadata today17:45
cardoeSo got an example of what gets generated?17:45
clarkbhttps://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L332-L39517:46
clarkbvs https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/_scripts.py#L125-L16017:47
cardoeSo 386 to 395 is roughly how all my python stuff looks even without pbr17:47
clarkbbecause 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 installation17:48
clarkbbut it can introduce significant slowness depending on the speed of your disks and how many packages are in python path17:48
clarkbanyway 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 done17:49
gouthamr+117:49
gouthamrthe handful of oslo folks are busy with eventlet atm17:49
clarkbone 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 efficient17:50
gouthamrthanks for summarizing this17:51
gouthamras next steps, we're looking for an assignee to tackle this in pbr17:52
gouthamrOct 31st is past the Flamingo release date17:53
gouthamrwill we be able to workaround and keep this situation from breaking CI while we work on the fix?17:54
gouthamr(if it comes to that) 17:54
clarkbhttps://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 ScriptWriter17:54
clarkbwriting our own version is probably doable if someone wants to dive into that17:54
fungiany 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 project17:55
fungiand may not be 100% viable17:55
gouthamryeah17:55
fricklerone other thing to note is that pbr CI is very broken currently. that also needs fixing before any real fixes can be applied17:56
gouthamrlets raise this through openstack-discuss, and also check with #openstack-oslo folks if anyone planned to look at this 17:56
gouthamrfrickler: ack17:56
gouthamrwe have ~3 mins17:57
gouthamrthe rest were regular topics17:57
gouthamrso i'll skip past these and lets take the remaining time for17:57
gouthamr#topic Open Discussion17:57
spotz[m]While FOrums are open in the CFP, do we want to submit a meetup?17:58
clarkbspotz[m]: when do forum session propsals close?17:59
spotz[m]Let me look17:59
noonedeadpunkI think it was smth 9th of July17:59
fungiso that's two weeks out if so18:00
noonedeadpunk8 July  23:59 PT, sorry (techynically 9 for me :D)18:00
spotz[m]Yeah we don't have a date, we do say we'll notify in July. Main CFP I believe will be notified tomorrow18:00
gouthamrCloses 8 July at 23:59 PST18:00
gouthamr#link https://summit2025.openinfra.org/cfp/ 18:00
gouthamr^ ah, spotz[m] knows better 18:01
noonedeadpunkand that was in email as well18:01
gouthamr:D i mean she's the program committee chair18:01
spotz[m]Had to log out and in from the tool - Accepting submissions until July 09, 2025 1:59 am America/Chicago18:01
spotz[m]I'll talk to Helena about adding it to the Summit page18:01
gouthamrit's on the page18:02
gouthamrokay, lets wrap it up18:02
gouthamrthank you all for attending18:02
gouthamrnext week's meeting will be held simultaneously on meetpad and IRC18:02
spotz[m]Thanks all18:03
spotz[m]And I don't see it on - https://summit2025.openinfra.org/18:03
gouthamr#endmeeting18:03
opendevmeetMeeting ended Tue Jun 24 18:03:30 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:03
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.html18:03
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.txt18:03
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.log.html18:03
clarkbfwiw I think the PBR changes have reasonable solutions its just that it requires someone to sit down and work through it all and maybe test with a hacked up setuptools that mimics the expected changes18:04
* gouthamr had a terrible time typing today trying to keep the keyboard out of the hands of a persistent baby 18:05
gouthamrack clarkb18:05
fungithat sounds decidedly worse than my cats trying to walk across or sit on my keyboard18:12
clarkbI stopped using gertty because it was easier to review on a phone or tablet than a device with a keyboard when the kids were small18:12
fungias of nowish, any zuul jobs using generic nodesets are getting nodes built and supplied by zuul instead of by nodepool (should be entirely transparent, just a heads up in case any unexpected differences are spotted)18:50
clarkbLooking at the PBR test failures I notice that using setup.py as a command will be removed on october 31 as well. This is easy to workaround and I think we haev in most places. Also develop is deprecated too. Not sure if that affects editable installs18:51
clarkbbut changes to develop/editable installs may have a bigger impact. I know devstack relies on them pretty heavily18:51
funginever mind, the zuul-launcher nodeset switch is being insta-reverted after spotting a problem, we'll try again once that's resolved19:09

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!