bauzas | gouthamr: I'm afraid I'll barely be able to discuss today at the TC meetign | 15:55 |
---|---|---|
bauzas | gouthamr: I'll be in some place where I can read the discussions but I won't really be able to interact | 15:55 |
gouthamr | ack bauzas thanks for letting me know | 15:58 |
gouthamr | tc-members: a gentle reminder that our weekly IRC meeting will be hosted here in ~59 minutes | 16:01 |
gouthamr | there’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 |
gouthamr | https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.org/thread/46X62IF7FIHHJTO4ICMLFDJOIKLSU25L/ | 16:02 |
gtema | gouthamr: I can't join today, have an appointment | 16:04 |
gouthamr | ack gtema | 16:05 |
frickler | zoom ... great | 16:10 |
gouthamr | haha, we have AI taking notes there 😄 | 16:11 |
spotz[m] | Thanks it wasn't on my calendar! | 16:16 |
gouthamr | #startmeeting tc | 17:00 |
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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
opendevmeet | The meeting name has been set to 'tc' | 17:00 |
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 |
gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting | 17:00 |
gouthamr | #topic Roll Call | 17:01 |
noonedeadpunk | o/ | 17:01 |
gmaan | o/ | 17:01 |
cardoe | \o | 17:01 |
frickler | \o | 17:02 |
gouthamr | noted absence: b a u z a s, g t e m a | 17:02 |
spotz[m] | o/ | 17:03 |
mnasiadka | o/ | 17:03 |
gouthamr | welcome everyone! lets get started | 17:03 |
gouthamr | #topic Last Week's AIs | 17:03 |
gouthamr | we took a couple of AIs last week to follow up on project inactivity and eventlet timelines | 17:04 |
gouthamr | 1) 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 |
gmaan | all good on this, PTL merged the ci fixes and other changes | 17:05 |
gmaan | that solve my concern at least for this cycle | 17:05 |
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:05 |
gouthamr | ack, we're still on a "sticky wicket" (heh, cricket reference) on cyborg's maintenance | 17:06 |
gmaan | that will be good checkpoint to re-iterate on this | 17:06 |
gmaan | yeah | 17:06 |
gmaan | we need to keep eyes on it | 17:06 |
gouthamr | ack, having no idea about how this works, can this project be considered mature or feature complete? | 17:06 |
gmaan | its hard to say feature complete as there are always more uses comes | 17:07 |
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 |
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 |
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 |
gouthamr | and migrate off of eventlet | 17:08 |
gmaan | yeah ^^ this one | 17:08 |
noonedeadpunk | it depends a lot on nova as well | 17:08 |
gmaan | yeah | 17:09 |
noonedeadpunk | so any major change in nova would require project to adopt | 17:09 |
fungi | eventlet now, but in the future whatever openstack-wide changes are identified too | 17:09 |
gmaan | in Nova, we keep it in backward compatible way but yes it needs to adopt new changes if there is any | 17:09 |
noonedeadpunk | well, they'd need to explicittly use other microapi version at least | 17:10 |
fungi | is cyborg exempt from rbac work? privsep improvement, etc... | 17:10 |
noonedeadpunk | I don't think they are? | 17:10 |
fungi | so 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 |
cardoe | well the project can be feature complete but maintenance is still required | 17:10 |
gmaan | rbac work is done for cyborg | 17:10 |
gouthamr | ^ they've completed privsep stuff | 17:11 |
gouthamr | nice | 17:11 |
gmaan | it is in much better place than many other project where RBAC and other work is not yet started :) | 17:11 |
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:11 |
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:12 |
gmaan | anyways, 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 accurate | 17:15 |
gouthamr | ack, ty.. the next AI was to propose an update to the eventlet goal | 17: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 proposal | 17:16 |
gouthamr | anything to discuss about this here? | 17:16 |
gouthamr | the important agreement i see here is that we don't _require_ eventlet support in python 3.13 | 17:18 |
gouthamr | too much to unpack there | 17:18 |
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:18 |
gouthamr | does that align with your understanding as well? | 17:20 |
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:20 |
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 |
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 |
fungi | er, for python 3.13 i mean | 17:21 |
gouthamr | i see | 17:21 |
fungi | the upcoming debian trixie release in about a month or so will only have python 3.13 | 17:22 |
fungi | and openstack is being included, just probably in a broken condition | 17:22 |
fungi | until (if ever) eventlet is patched to work on 3.13 | 17:22 |
frickler | iiuc the latest news was that there is a bug in cpython proper affecting nova on py3.13 | 17:22 |
gouthamr | ah, so we have bigger/different problems too | 17:24 |
frickler | #link https://github.com/python/cpython/issues/135552 | 17:24 |
gouthamr | ty | 17:24 |
gouthamr | alright that's all the AIs i recall, was anyone else working on anything else | 17:24 |
mnasiadka | Well, 2025.2 is not SLURP, so let's hope not many people are going to go the Trixie+OpenStack route | 17:24 |
fungi | no, they're shipping openstack 2025.1 (slurp), 2025.2 won't be available in time for trixie | 17:25 |
fungi | so it's openstack 2025.1 with python 3.13 | 17:25 |
fungi | (plus whatever future patches fix it into a working condition) | 17:26 |
bauzas | (can't really comment, just reading) | 17:26 |
gmaan | 2025.1 does not support py3.13 so there might be more issues? | 17:26 |
gouthamr | that wasn't even on our runtime :( they'll have a hard time with the backports i suppose | 17:26 |
gmaan | yeah | 17:26 |
fungi | yeah, the distro doesn't take that into account when deciding what version of python it's going to include | 17:26 |
gouthamr | for sure | 17:27 |
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 |
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 |
gmaan | that is also fair | 17:27 |
gouthamr | yeah, lets please continue the discussion on gerrit | 17:28 |
gouthamr | #topic Updating inactive projects | 17:28 |
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:28 |
gouthamr | M-2 is in a couple of weeks, was wondering if anything had to be discussed wrt inactive projects? | 17:29 |
gouthamr | my bad | 17:30 |
gouthamr | its next week | 17:30 |
bauzas | gmann: I'll try | 17:30 |
gmaan | thanks. no hurry. | 17:30 |
gouthamr | sounds like no.. lets move on | 17:32 |
gouthamr | #topic setuptools and pbr | 17:32 |
gouthamr | we were chatting on #opendev a few days ago about a deadline wrt setuptools supporting something pbr has relied on | 17:33 |
cardoe | what specifically? | 17:33 |
clarkb | specifically the ScriptWriter tooling to write out entrypoint scripts for command line tools and the wsgi scripts | 17:33 |
fungi | setuptools wants to remove pkg_resources later this year | 17:34 |
clarkb | fungi: thats the toehr thing | 17:34 |
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 |
clarkb | ScriptWriter was part of vendored easy_install which is getting completely removed | 17:34 |
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 |
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 |
fungi | #link https://bugs.launchpad.net/pbr/+bug/2107732 covers the scriptwriter case | 17:35 |
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:36 |
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 |
gouthamr | #link https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/command/easy_install.py#L27 (deadline in setuptools) | 17:37 |
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 |
cardoe | setuptools seems to be more becoming a library for other frontends to take over. Like the script stuff. | 17:38 |
cardoe | They're nudging people actively to hatch for example. | 17:38 |
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:38 |
clarkb | and pkg_resources is going away because importlib replaces it | 17:39 |
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 |
cardoe | fungi: yes but projects want to remain consistent so they use that. | 17:39 |
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 |
cardoe | I've been -1'd on that change to drop the runtime depend on pbr. | 17:40 |
cardoe | But anyway, I've shifted away from the convo. | 17:40 |
fungi | yes, runtime pbr use is essentially unaffected here, it's dist build that's the problem | 17:41 |
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 |
fungi | vendoring or fixing is probably equal amounts of work | 17:41 |
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 |
fungi | in many cases, the "fix" is to just drop more code and now redundant features from pbr | 17:42 |
clarkb | then for pkg_resources we need to prefer importlib everywhere in pbr with a fallback to pkg_resources for old setuptools | 17:42 |
cardoe | My vote would be to lessen our maintenance burden by preferring the upstream path. | 17:42 |
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 |
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 |
fungi | pbr *is* "oslo stuff" btw (it was originally named oslo.packaging when it was first extracted from openstack/common in nova) | 17:43 |
clarkb | note the less efficient startup cost is possibly measured in seconds for tools like osc on slow disks | 17:43 |
cardoe | We'll have another one when they get rid of setup.cfg support for pyproject.toml | 17:43 |
gouthamr | clarkb: that would be terrible for OSC plugins | 17:44 |
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:44 |
clarkb | I suppose another option is to work with upstream to fix their slow scripts then adopt them | 17:45 |
fungi | pbr already translates old distutils setup.cfg directives to setuptools-recognized metadata today | 17:45 |
cardoe | So got an example of what gets generated? | 17:45 |
clarkb | https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L332-L395 | 17:46 |
clarkb | vs https://github.com/pypa/setuptools/blob/1fe0c5d2f46e141d6097910d2905a3fce5e30c52/setuptools/_scripts.py#L125-L160 | 17:47 |
cardoe | So 386 to 395 is roughly how all my python stuff looks even without pbr | 17:47 |
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 |
clarkb | but it can introduce significant slowness depending on the speed of your disks and how many packages are in python path | 17:48 |
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 |
gouthamr | +1 | 17:49 |
gouthamr | the handful of oslo folks are busy with eventlet atm | 17:49 |
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:50 |
gouthamr | thanks for summarizing this | 17:51 |
gouthamr | as next steps, we're looking for an assignee to tackle this in pbr | 17:52 |
gouthamr | Oct 31st is past the Flamingo release date | 17:53 |
gouthamr | will 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 |
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 |
clarkb | writing our own version is probably doable if someone wants to dive into that | 17:54 |
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 |
fungi | and may not be 100% viable | 17:55 |
gouthamr | yeah | 17:55 |
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 |
gouthamr | lets raise this through openstack-discuss, and also check with #openstack-oslo folks if anyone planned to look at this | 17:56 |
gouthamr | frickler: ack | 17:56 |
gouthamr | we have ~3 mins | 17:57 |
gouthamr | the rest were regular topics | 17:57 |
gouthamr | so i'll skip past these and lets take the remaining time for | 17:57 |
gouthamr | #topic Open Discussion | 17:57 |
spotz[m] | While FOrums are open in the CFP, do we want to submit a meetup? | 17:58 |
clarkb | spotz[m]: when do forum session propsals close? | 17:59 |
spotz[m] | Let me look | 17:59 |
noonedeadpunk | I think it was smth 9th of July | 17:59 |
fungi | so that's two weeks out if so | 18:00 |
noonedeadpunk | 8 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 tomorrow | 18:00 |
gouthamr | Closes 8 July at 23:59 PST | 18:00 |
gouthamr | #link https://summit2025.openinfra.org/cfp/ | 18:00 |
gouthamr | ^ ah, spotz[m] knows better | 18:01 |
noonedeadpunk | and that was in email as well | 18:01 |
gouthamr | :D i mean she's the program committee chair | 18:01 |
spotz[m] | Had to log out and in from the tool - Accepting submissions until July 09, 2025 1:59 am America/Chicago | 18:01 |
spotz[m] | I'll talk to Helena about adding it to the Summit page | 18:01 |
gouthamr | it's on the page | 18:02 |
gouthamr | okay, lets wrap it up | 18:02 |
gouthamr | thank you all for attending | 18:02 |
gouthamr | next week's meeting will be held simultaneously on meetpad and IRC | 18:02 |
spotz[m] | Thanks all | 18:03 |
spotz[m] | And I don't see it on - https://summit2025.openinfra.org/ | 18:03 |
gouthamr | #endmeeting | 18:03 |
opendevmeet | Meeting ended Tue Jun 24 18:03:30 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:03 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.html | 18:03 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.txt | 18:03 |
opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.log.html | 18:03 |
clarkb | fwiw 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 changes | 18:04 |
* gouthamr had a terrible time typing today trying to keep the keyboard out of the hands of a persistent baby | 18:05 | |
gouthamr | ack clarkb | 18:05 |
fungi | that sounds decidedly worse than my cats trying to walk across or sit on my keyboard | 18:12 |
clarkb | I stopped using gertty because it was easier to review on a phone or tablet than a device with a keyboard when the kids were small | 18:12 |
fungi | as 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 |
clarkb | Looking 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 installs | 18:51 |
clarkb | but changes to develop/editable installs may have a bigger impact. I know devstack relies on them pretty heavily | 18:51 |
fungi | never mind, the zuul-launcher nodeset switch is being insta-reverted after spotting a problem, we'll try again once that's resolved | 19:09 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!