18:00:10 #startmeeting tc 18:00:10 Meeting started Tue Sep 10 18:00:10 2024 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:10 The meeting name has been set to 'tc' 18:00:28 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. 18:00:32 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:00:36 #topic Roll Call 18:00:53 o/ 18:00:57 o/ 18:00:58 o/ 18:01:00 \o 18:01:07 o/ 18:01:13 o/ 18:01:17 o/ 18:02:09 courtesy ping spotz[m] noonedeadpunk 18:02:18 Here! 18:02:25 * gouthamr :D matrix 18:03:08 o/ 18:03:30 hello everyone! let's get started 18:03:39 #topic AIs from last week 18:04:15 we took a note to start the PTG etherpad; i'll bring that up in a sec 18:04:42 i voluntold spotz[m] to capture feedback from the Suwon summit; we'll check on that in a bit as well :) 18:05:04 gmann: target merging the requirement bump for oslo.policy 4.4.0 by the Feature Freeze deadline 18:05:15 ^ this happened when we were in the meeting iirc 18:05:21 yeah 18:05:51 #link https://review.opendev.org/c/openstack/requirements/+/925464 (update constraint for oslo.policy to new release 4.4.0) 18:06:08 i see that you're helping some folks deal with the fall out of this on the ML; thanks gmann 18:06:25 was there any other developments to share wrt this item? 18:06:37 nothing else 18:06:44 ack ty 18:06:51 slaweq: revive the "leaderless" projects etherpad to manage the situation for projects without maintainers (mistral, swift, watcher, kuryr) 18:07:21 #link https://etherpad.opendev.org/p/2025.1-leaderless (Leaderless projects for 2025.1) 18:07:26 https://etherpad.opendev.org/p/2025.1-leaderless 18:07:32 this is etherpaad I did 18:07:35 ^ slaweq populated this and shared this after our meeting last week 18:07:56 * gouthamr adds it to the tracker.. 18:07:58 ty slaweq 18:08:05 thx 18:08:48 think that was all the AIs I was tracking; were there any other action items you folks were pursuing? 18:09:54 taking silence to mean we've got everything.. let's move on to the next topic 18:10:07 #topic 2025.1 PTG 18:10:13 #link https://etherpad.opendev.org/p/oct2024-ptg-os-tc (TC Oct 2024 PTG Etherpad) 18:10:47 ^ here's a scratch space for us to gather topics and dump initial ideas that we'd like to bring to the discussion at the TC's PTG 18:11:54 please bookmark this etherpad; so you can fill it up with your thoughts over the next few weeks 18:13:05 any thoughts/concerns regarding the PTG? 18:13:47 Only that a lot of teams hadn't signed up last I checked, I know some teams do their own stuff throughout the cycle though 18:14:22 ah true 18:14:31 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/XHCL5D7ODOP3GLIIXZOCTZF45KLXZD5G/ (PTG October 2024 Team Signup) 18:15:09 diablo_rojo didn't share a list past the sign up deadline; spotz[m] do you know if this list increased? 18:15:38 Not that I know of but she was traveling for the last 2 weeks I think 18:15:55 ++ 18:16:46 yes; we might get an update alongside a request to plan slots on the schedule 18:17:36 we've ~46 project teams; and several SIGs and WGs as well - i do expect to see that list to have increased a bit more after the reminder 18:19:00 anything else about $topic? 18:20:21 lets move on.. 18:20:21 #topic Release team project health check 18:20:27 #link https://etherpad.opendev.org/p/dalmatian-relmgt-tracking#444 (Release team project tracking) 18:20:39 frickler shared this on the channel in the past week 18:21:17 I think the link misses an "L", also stuff moved again 18:21:22 AH 18:21:40 this ia about the "Project teams health scorecard" 18:21:43 https://etherpad.opendev.org/p/dalmatian-relmgt-tracking#L452 18:22:57 so missing a release review can happen, but if it repeats, this is reason for concern IMO 18:23:26 but I'm also not sure what we can actually do about it, ideas welcome 18:23:30 goes along with elodilles's post on the ML as well: 18:23:38 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QBNRSPUROJYTF2E3TYZLRPL6WDZTAFXJ/ ([horizon][ironic][swift][qa] cycle-with-intermediary deliverables without recent release) 18:25:15 regarding bot patches: sometimes CI's failing and no-one's looking at these and they'll eventually get buried 18:25:53 but, many bot patches are ignored even when CI votes positively 18:26:01 just an example: https://review.opendev.org/c/openstack/venus/+/913417 18:27:16 we can remind PTL/DPL Liaisons that they must press the buttons and merge these.. very little likelihood that these patches need a ton of attention from someone working on the projects 18:27:39 if the bot/tooling is broken the release team would find out very soon 18:29:24 I'd really like to hear other TC member's opinions on this 18:29:34 * slaweq needs to finish earlier today, sorry for that 18:29:55 * slaweq will catch up with rest of the discussion from the logs 18:30:04 test 18:30:34 maybe we could use a timely reminder to the release liaisons of each project regarding this sorta thing... it shouldn't be something that deems a project "unhealthy" (although unfortunately is) 18:30:39 spotz[m]: passed 18:30:42 slaweq: ack 18:31:19 most affected projects don't have release liaisons other than the PTL 18:31:20 Had a message my connectivity had been dropped:( 18:32:05 maybe s/most/many/, that's just off the top of my head 18:33:03 I think we discussed it many time in past about making PTL/release liaison +1 a mandatory requirement to release their deliverables 18:33:32 and release team were not comfortable on that as it can leave many project unreleased or delay the final release 18:33:39 yes, we even have the ptl-approved flag for release changes 18:33:45 yeah 18:33:49 but we often need to override it 18:34:08 but unless that is mandatory I am not finding that flag as very useful as release happen without their +1 also 18:34:50 so you would not release some things, then? 18:35:04 making it mandatory has its own pros and cons 18:36:11 I am not saying do not release, if we are releasing then it is ok if PTL/liaisons are not ack that 18:36:13 Like, what's the value? If we're trying to encourage behavior, I don't think being punative does the trick. 18:36:47 yeah 18:36:48 I think about ways we can put the next step in front of people's faces, in the same way was done for elections -- emailing all contributors that PTL is needed. 18:37:08 as frickler you mentioned earlier, I am also not sure what TC can do actionable on this? 18:37:11 and leave it to release team 18:37:30 Many of our contributors, especially for smaller projects, are likely just not embedded enough in openstack-life to know they missed a thing. 18:37:58 which is a problem in itself I think 18:38:41 I don't disagree, but there's no pool of extra-engaged contributors to pull from -- so the options are try to make it easier for someone to engage part time or to lower scope to that which we have enough engaged contributors on. 18:38:50 if they are volunteer to maintain projects then release is the very first things they should care about 18:39:04 So there are tradeoffs; but I don't think moving policies around about +1ing something on time is going to make a difference to folks who likely are missing they need to do the thing in general. 18:39:22 I do not think we can lower scope than 'do not care about release' 18:39:34 * lower scope *to* 18:39:37 gmann: honestly, that's not been true at almost any place I've worked. Many people consume from git, and treat releases as neccessary chores rather than the goal. 18:39:52 I know this election cycle as far as PTLs is over. But would it help to have an onboarding/responsibility session at the PTG and/or before the next election? 18:40:19 gmann: so I agree in theory, but in a world where people have limited time & attention; I can see why that gets missed 18:40:26 yeah but not all right and as maintainer of project I need to take care of all kind of users, git consumer, released consumer etc 18:40:40 spotz[m]: I think so; we can definitely bring this up in the TC+project leadership discussion that we'll likely plan 18:41:29 I think everyone knows about this responsibility and we have discussed it many times in TC PTGs also. 18:41:58 I think unless we are making it mandatory there is less hope in improvement which is fine for me 18:42:27 I mean how things are going is ok unless release team raise some alert for TC to take action on 18:42:27 as a release liaison for a project for several years; and a downstream consumer as well - I agree a bit with JayF .. In most cases, i'm okay with the release team releasing any merged code.. my involvement has been to point over semver changes or hold off something to get a few more patches in 18:42:45 so its my -1 that matters more than my +1 really 18:42:59 you'd be surprised how many (relatively popular) open source projects don't even bother to make releases at all 18:43:23 gmann: my point is more that if someone's pager is going off, and they're fixing security bugs, and generally busy, doing the "paperwork" for a release might be something that slips their mind. I know when I was PTL that happened a time or two. 18:43:26 fungi++ 18:44:04 That's why I'm mainly saying I think thinking in a direction of "how can we enable people to see the signal of 'release maintenance' in their noisy work life otherwise" 18:44:20 the PTL-needed emails to contributors for the election is an A+++ example of us doing this to positive effect 18:44:50 sure, then we should continue it as it is and let release team handle it as their best effort. 18:45:30 and probably publish their thoughts to the ML about the pain points 18:45:48 well, with my release team hat on, I would like to have an option to avoid having to chase +1's from PTLs 18:46:05 but maybe we need to discuss this within the release team first 18:46:07 I think release team send a good reminder on the release deadlines, it helps. I get reminder about Tempest release evrytime I see release email 18:46:23 frickler: ++ 18:46:31 frickler: fwiw, I'd generally be ok with a "you have a set time to veto the patch with a -1" policy; but I also think we should pair it with ways to help engage folks too 18:46:42 frickler: but I think we shouldpair everything with that so :) 18:47:42 frickler: thanks for bringing this up; i'd like to wrap up the discussion with what you said: "discuss this within the release team first" 18:48:03 +1 18:48:33 okay; lets move to regular programming 18:48:38 #topic A check on gate health 18:48:58 any gate issues to discuss this week? 18:49:27 we have the new raxflex cloud in operation now 18:49:56 yeah, it's not a lot of quota yet (32 nodes), but keep an eye out for any job failures that might be specific to that location 18:49:58 and there seems to have one issue because this is the first cloud in some time that uses internal network + FIPs instead of provider network again 18:50:24 the swift team discovered for example that they were baking in assumptions that the public ipv4 address was bound locally on interfaces 18:50:25 ya swift hit that but they were also able to fix it quickly 18:50:27 ^ crap i know devstack-plugin-ceph may have a problem with that 18:50:53 etcd3 also needs a local bind address i think 18:51:28 considering that everything hasn't caught fire they may be using 0.0.0.0 18:51:45 in swift's case they were trying to bind only to the fip specifically which isn't configured on the host and that failed 18:51:51 but switching to 0.0.0.0 would fix it 18:53:07 noted clarkb.. i'll keep a look out if multinode ceph jobs run okay here; binding MONs, Ingress/NFS to 0.0.0.0 or even a local IP would work fine for single node 18:53:47 but new capacity is good news 18:53:56 thank you for sharing the news, frickler 18:54:22 * gouthamr "sjc3" - US west coast too, nice 18:54:36 Whoa, that *is* a new Rackspace site! 18:55:37 anything else about the gate? 18:56:07 * gouthamr would like to skip over the TC tracker and discuss any open items in Open Discussion 18:56:12 #topic Open Discussion 18:56:54 spotz[m]: i meant to chat prior to the meeting to seek a Suwon recap; but would you be able to do that for us next week? 18:57:18 Might be worth noting that 18:57:19 #link https://www.socallinuxexpo.org/scale/22x/events/open-infra-days 18:57:28 Sure, and it was videoed! It was really just a nice chat with a potential new contributor 18:57:32 OpenInfra Days in NA next year is co-located with SCALE, in March 2025 18:57:36 About 7 folks in the room 18:58:08 very nice 18:58:22 Yeah and SCALE's CFP is open and our talks will go through there but we haven't started work on it yet, trying to get through Indy first:) 18:58:39 ends November 1 right? 18:59:21 yes 18:59:36 #link https://www.socallinuxexpo.org/scale/22x/cfp (CFP for SCaLE '25) 18:59:56 alright folks; we're at the top of the hour.. 19:00:07 thank you all for attending 19:00:14 I'll note Julia and I spoke at SCALE20x, it's a nice conference and I suggest proposing talks -- OpenInfra-y or not. 19:00:16 will see you here again, next week 19:00:20 o/ ty gouthamr 19:00:21 JayF++ 19:00:27 #endmeeting