17:00:45 #startmeeting tc 17:00:45 Meeting started Tue Sep 23 17:00:45 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:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:45 The meeting name has been set to 'tc' 17:01:43 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:01:46 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 17:01:48 #topic Roll Call 17:01:50 o/ 17:01:58 o/ 17:02:00 o/ 17:02:19 \o 17:02:21 * gouthamr passes some strong coffee to tonyb 17:03:24 courtesy-ping: spotz[m], cardoe, mnasiadka 17:03:35 O/ 17:03:45 I’m on 17:03:48 ^ i refreshed the ping list, please do edit it on the wiki if you want to be alerted 17:03:56 Kinda. Gimme 3 minutes. 17:04:01 noted absence: b a u z a s 17:04:13 cute 17:06:04 alright, lets get started.. 17:06:04 first off, congratulations on your (re)election to the TC, cardoe frickler ba u zas and tonyb 17:07:29 and lets take a moment to acknowledge the long hours of work its taken to run the elections - ianychoi and slaweq did a great job as always, and continued to make the process better by adopting feedback expeditiously 17:08:05 agreed. cheers folks on another job well done. 17:08:34 also as gmaan_pto takes a well needed break, i do hope he'll still join us in these meetings when he's back! 17:09:16 * tonyb applauds 17:09:27 there's a governance patch formalizing these changes: 17:09:27 #link https://review.opendev.org/c/openstack/governance/+/961598 (Add TC/PTL results from 2026.1 election) 17:10:03 but that needs https://review.opendev.org/c/openstack/election/+/961596 17:10:25 ^ slaweq ianychoi if you'd like to merge that elections repo change and make further changes, i don't mind 17:11:03 frickler: ^ if you're okay with creating another patch to fix the nick.. 17:11:41 several IRC nick fixes need to be done, but unless they can be done super quick, lets avoid them 17:12:09 Looks like a few more manual updates needed before we can approve. 17:13:25 doc updates are trivial, wanted to merge these and formalize the results though since it concludes the election process 17:13:34 #topic Last Week's AIs 17:14:30 we took a note to check on the electorate, crunching numbers and share feedback on openstack-discuss: 17:14:33 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CMBMBPWDCQHFSCYGUWMBZHVOB2K7EILB/ 17:15:27 we can follow up on this thread, and make any recommendations and follow up.. i'll bump this topic to next week 17:16:05 next up: status check on the "leaderless" projects 17:16:24 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/G4FSLQDGJBRY6G4JQ3SSIPN2UVX7BC4K/ (Venus) 17:16:37 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/22GL7TB54WY4T2JDEVKFQCEKQY4AAVAN/ (Vitrage) 17:16:40 o/ 17:16:50 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WR277VO5VNJP2Z5WPZ7RPWRSW2Y7F7CT/ (OpenStack Charms) 17:17:26 freyes_ responded on the last thread here.. we need an appointment patch to be raised on openstack/governance 17:17:54 and i was hoping to get some clarity on the state of the Charms project - i.e., is it actively maintained, how does one approach the maintainers 17:19:23 they have a ton of repos too, would be great if the new ptl looked into retiring any that are no longer needed/maintained 17:19:39 ah true 17:20:39 regarding Venus: i was planning to run the project_stats tool to share some insights, but, a peek on gerrit tells me: 17:20:39 - there was little to no activity on the repos in the 2025.2 cycle 17:20:39 - the release team identified that CI is broken on the "openstack/venus" repo 17:20:42 #link https://review.opendev.org/q/topic:release-health-check-flamingo+is:open 17:20:50 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CVWXC6RRTBWRDNQR2TTMT6FN4ZNUVJHH/#57BOQXZ563BAJOLGHYWURRQNDEORKILA 17:20:54 Felipe Reyes proposed openstack/governance master: Appoint Felipe Reyes as PTL for OpenStack Charms https://review.opendev.org/c/openstack/governance/+/962121 17:21:05 freyes_++ 17:21:08 gouthamr, ^ , does this look ok? 17:22:21 freyes_: it does, ty.. do you mind watching comments on that change and responding to them.. 17:23:02 freyes_: we have a bunch of questions on Charms that we need some clarity on - might be tangentially related to the PTL appointment itself 17:23:54 gouthamr, ack, I'm into back-to-back meeting for the next few hours, but will circle back before going offline today 17:24:06 freyes_: great, ty 17:24:20 np, thanks to you 17:24:54 regarding venus, we can discuss the status thoroughly next week once we have the project-stats o/p.. 17:25:36 we're waiting on vitrage in the same manner - but this one has had maintenance activity on gerrit 17:25:47 and noonedeadpunk had been shepherding it until recently 17:26:38 short of saying "you're it again" noonedeadpunk, i'm unsure about the implications here.. the core-team is huge 17:27:22 but some email addresses are no longer active 17:27:55 to new ptl: please pare that list down to active participants 17:28:22 gouthamr: majority of the Gerrit core group is my former team in Nokia/Cloudband, it seems it hasn’t been cleaned up in a very long time 17:28:34 yeah, it was not 17:28:50 I didn't do that so far :( 17:29:17 Um, I still didn't get time to check on vitrage tempest, which I planned for the past week 17:29:46 and I was thinking to myself that on solving tempest would depend if I'd be able to step again into these shoes again or not 17:30:20 yes, is this a project that's surviving on your goodwill/availability? or is this useful to form a community around? 17:31:34 maybe these are tough questions and we can take some time to tackle this - feel free though to share the situation on the ML 17:31:54 if there are users out there, they may be under the assumption that we've got the situation handled 17:34:02 i think the next AI can be marked complete too: 17:34:02 vendoring the ply library into yaql with the TC's approval: 17:34:02 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4/#PKWNZ7QL6PRJI2WXMMWYYZYWYZA3Z7E4 17:34:02 #link https://review.opendev.org/c/openstack/yaql/+/961398 17:34:28 well, I think that it's really important especially for newcomers to ecosystem to build awareness about operational principles 17:34:39 and can show a way on how to debug issues when they arise 17:34:45 ah! 17:34:52 i hadn't thought of that use case 17:34:57 but like... I was not able to convince to add to our production even... 17:36:21 ack, if there's a worthwhile improvement to be made to make things more attractive/usable, i would suggest working with diablo_rojo_phone to identify student interns 17:36:29 or even outreachy 17:36:52 although it'll need more of your already limited time to coach contributors 17:37:07 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PBQSHMZIYXHKA7OD756OAJS4OZOHMGWK/ 17:37:14 ^ silent plug for outreachy 17:37:54 (it looks like we have funding \o/ - it'd be nice to have mentor/s and an intern to continue this engagement!) 17:38:12 we have funding for one intern for the December cohort 17:38:28 i'll note that zigo raised concern over the idea of copying ply into yaql from a package maintainer perspective, vs maintaining it as a stand-alone python library. i haven't looked to see what the reverse-dependencies of python3-ply in debian might be (besides python3-yaql obviously) 17:38:41 I'd reather put that towards freezer tbh, as way more important project.... 17:39:08 We were lucky enough to get funding for 1 intern each cohort this year. Using the spot justifies for next year 17:39:19 ++ 17:39:39 fungi: Answer is: A LOT. https://paste.opendev.org/show/bJa1wpmbbTlrRFNSucOD/ 17:39:42 I will definitely have universities looking for project proposals November/ decemberish. 17:39:49 Which is why I see no point embedding ... 17:39:54 We just missed the current semester by a month or so. 17:39:58 Someone will for sure fork or take over maintainership. 17:40:27 it seems like the current maintainer doesn't want to stop maintaining it. They just don't want to deal with python packaging so a fork seems more likely if it goes that route 17:40:30 zigo: thanks, that's more than i expected 17:40:50 that said its small and self contained and it doesn't do network connectivity. Its like the perfect thing to vendor... 17:41:45 yeah, but if every project that uses ply vendors its own copy, they will become out-of-sync near-duplicates that all need to be patched the next time there's a security vulnerability discovered in it 17:42:18 at least that's the typical concern raised at the distribution level 17:43:14 so the distro is going to strip out yaql's copy of ply and try to patch in a shared copy that only needs to get fixed in one place for all the projects that need it 17:43:15 vendored code is now project code no? i mean, we'll be in line to maintain/patch it for the future.. so vulnerabity scanning tools for instance will have to see the changes in the yaql library 17:44:24 fungi: i hope not, because theoretically, we could alter it's behavior now and make it incompatible with ply 17:45:35 yes, that's the bigger risk. but basically the distro would prefer to patch the python3-ply package rather than patching the same vulnerability in 25 separate packages that vendor slightly divergent copies of it 17:45:57 understood 17:46:40 one option may be to do something like build a python package repo for it and auto update ply via a git submodule or something 17:46:56 it may be worth talking to the maintainer to see if tehy would be interested in someone else doing that work 17:47:35 (this is also why it's almost impossible to package a lot of typical javascript projects, because they all like to rely on internal copies of different versions of dependencies) 17:49:24 there's a meme for that 17:49:28 So losing what we want to do with this one? 17:50:28 we're considering the implications to distros, and actively taking notes on the next situation.. i don't think we'd change the situation with openstack/yaql 17:51:13 i would just make absolutely certain there's not some way to have ply as a separate dependency before deciding to copy it into yaql, since this choice is an added burden for downstream package maintainers and needs to be recognized as such 17:52:06 If the author is not interested just in packaging (and new features) can we just reference it using git+https instead of pypi? 17:52:18 and yaql is apparently one of 25 projects packaged in debian that share this dependency, so we should avoid making decisions in a vacuum 17:53:06 mnasiadka: that only works if there is packaging toolin in the repo 17:53:23 (which does exist for now) 17:55:10 well https://review.opendev.org/c/openstack/yaql/+/961398 was merged, do you want to revert this? not sure who actually maintains yaql 17:55:17 if it turns out that the ply maintainer doesn't share concerns about reusability and the impact on downstream consumers and packagers, then migrating to or maintaining an alternative solution could be on the table too 17:55:37 by vendoring that code, we've created that alternative solution 17:56:01 we've solved it for yaql, but not the other 24 projects that use it 17:56:32 and if they all "solve" this the same way, it's problematic 17:56:35 for sure.. 17:56:35 you could actually just have a zuul job publish the library to pypi under a different name as long as the repo contains packaging tooling in it 17:57:18 as a service we could offer to the ply maintainer? but then, we need someone to do it for perpetuity, no? 17:57:33 not against it, just wanted to see how that would work with our community 17:57:47 our "deliverables" are maintained by project teams and SIGs 17:57:55 I was thinking you'd do it without their involvement as tehy aer interestd in releases and publishing packages 17:58:03 just noting there are other projects i'm involved in that also appear on the list of ply's reverse-dependencies, so those will eventually need to take action as well if ply stops providing packaging 17:58:14 Well, gertty is also on the list, so we’ll at least host two ,,versions’’ of ply in OpenDev it seems 17:58:32 I like the git submodule approach, that seems like a reasonable balance. 17:59:10 I think we can leave https://review.opendev.org/c/openstack/yaql/+/961398 in place for now 17:59:22 it seems like they don't want to manage the overhead of deciding when relaeses should be made and publishing them as packages 17:59:39 so if not forking entirely filling that void is probably where you can be most helpful 17:59:39 so not just packaging but also releasing 18:00:10 and give me an AI to talk the ply maintainer about their willingness to work with that (or some other route) and bring that back 18:00:31 so ... lots of options of what might be done ... but is there any volunteer to actually do anything about this? 18:00:58 sounds like one on tonyb :) 18:01:01 with more information from the maintainer and possibly the other ply users we may have a better answer 18:01:12 * gouthamr we're over the hour 18:01:38 cardoe: would you like to chat about the skyline topic after the meeting? 18:02:02 Sure 18:02:03 or is it okay to wait until next week? 18:02:09 but also if we do choose to just stick with the current solution in yaql, we can acknowledge that it was the easy way out and that we understand it wasn't optimal for downstream distributions 18:02:12 I mean I'd just like to see skyline work. 18:02:31 The CI has been busted for a while. I'm not even sure how the last patches were merged in because the issue is that the Zuul config is wrong. 18:02:54 skyline has this exact problem, but magnified tenfold (thanks javascript!) 18:03:00 cardoe: think it'll be nice to have everyone here for that topic, so i can push it to next week 18:03:14 we're past the RC deadline, so hopefully the patches you're chasing can wait? 18:03:32 or are they release blockers?' 18:04:04 cardoe: the issue is related to the ansible 11 by default update in zuul itself 18:04:14 cardoe: so presumably the last change that merged did so before the zuul default updated within opendev 18:04:25 ah well that makes sense 18:04:41 gouthamr: well the 2025.2 release commits fail from that. 18:04:43 the skyline maintainers sent a list of release highlights to the foundation's china community manager because they didn't know the process for adding them to the upstream release repo list. i've tried to communicate some of these concerns back through the same channel 18:04:56 :( 18:04:59 re ply the author has stated "If you use PLY, you should copy it into your project." but they may accept a middle ground 18:06:12 fungi: the team needs to extend to actually sustain this useful project.. think cardoe's interest in this is great! 18:06:19 alright we're 6 minutes over 18:06:28 yes, i tried to pass that along to them 18:06:52 i'll wrap this up, sorry we didn't get through a lot today.. please don't let this wrap up stop any time critical discussion 18:07:02 thank you all for joining 18:07:06 #endmeeting