18:00:24 #startmeeting tc 18:00:24 Meeting started Tue Jan 21 18:00:24 2025 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:24 The meeting name has been set to 'tc' 18:00:50 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:55 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 18:01:00 #topic Roll Call 18:01:03 o/ 18:01:04 \o 18:01:16 \o 18:01:36 I'll probably miss next week. I'm on PTO and not sure where I'll be at the time of the meeting. 18:01:38 o/ 18:01:47 cardoe: ack 18:02:12 noted absence: s l a w e q 18:02:16 o/ 18:02:37 courtesy-ping: gmann, spotz[m] 18:02:54 o/ 18:02:59 o/ 18:03:22 that's everybody; thank you for joining.. lets get started.. 18:03:28 #topic Last Week's AIs 18:03:40 noonedeadpunk: many thanks for running last week's meeting :) 18:03:53 sorry for not sending notes :( 18:04:03 there was not much things though 18:04:22 no problem! i had the log and captured some AIs from there: 18:04:43 proposal on dealing with poorly maintained repositories that can't be deprecated/retired, case in point openstackdocstheme 18:05:25 ^ noonedeadpunk this was assigned to you.. would you like to move it to the TC tracker? don't think there's any urgency here.. right? 18:05:41 yeah, so this scenario was kinda sorted out by providing gtema access 18:06:06 so indeed no urgency should be so far 18:06:16 yeah, still w+ is missing on os-api-ref to proces dependencies 18:07:33 no, vice-versa, I have +2/+W on os-api-ref but not in openstackdocstheme 18:08:02 i think that needs help from the oslo team to add 18:08:39 ah; ty.. oslo-core is a pretty slim group 18:09:08 maybe we can ping tkajinam / stephenfin or hberaud to assist here 18:09:28 gtema: oh, I thought last week gmann said he grated you openstackdocstheme 18:09:29 I added it in the oslo team meeting agenda couple of week back but we can check if that has been discussed or not 18:09:44 at least I was under this impression 18:09:56 I think they're all in this channel though maybe not awake 18:09:56 noonedeadpunk: not yet I think, I left oslo core member to add it 18:10:16 I see 18:10:16 gmann: i don't think they've met this year, yet? 18:10:23 gmann: https://meetings.opendev.org/meetings/oslo/ 18:10:32 here is discussion 18:10:34 #link https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking#L95 18:11:34 ah; no meeting yet by the looks of it. 18:11:39 I can check with damani and check the plan to discuss/add gtema in core list of openstackdocstheme 18:12:26 :) i'd hold off and ping someone else 18:12:36 he'd be afk for a few more weeks.. 18:13:06 i can follow up, gmann and gtema 18:13:15 just pinged in oslo channel 18:13:42 last time it was discussed, there was no objection but we wanted to discuss it with all core members mostly after holidays 18:13:53 ++ 18:14:35 ty gmann 18:14:39 anything else about this AI? 18:16:48 okay, moving on.. we discussed elections and allowing early nominations but i don't think we closed the loop on this 18:18:05 election officials have not completed the "kickoff" activities as yet - one of which is to setup the directories 18:18:10 there's no candidates/2025.2 directory in the election repo yet, so too soon for candidates to start proposing their nominations 18:18:10 what else then ? 18:18:36 do we have candidates that nominate themselves before the nominations start ? 18:18:36 bauzas: can i tack an AI on you to track this stuff? 18:18:41 * noonedeadpunk needs to propose resolution for late freezer release :( 18:18:54 gouthamr: shoot 18:18:54 noonedeadpunk: noted 18:19:15 I'll doublecheck with the elections folks 18:19:35 i don't see any changes to add it proposed yet either 18:20:01 (the election candidates directory i mean_ 18:20:06 ack.. 18:20:13 my point is, if anyone can propose themselves now, why do we need to wait until Feb 5 then ? 18:20:27 I thought the directories were there, looking for the tab of my last pull 18:20:43 if this is just for signaling that election officials will review your patches by that date, then that sounds a procedural detail 18:20:55 there is no restriction on candidate itself add dir with placeholder or candidacy 18:20:55 yes that's what it means.. 18:21:15 proposed nominations prior to the start of the nominations period have to be rechecked within the nominations window to get a passing ci result, i think (unless that has changed more recently), but otherwise there's nothing stopping someone from proposing their nomination once the directory structure for the election has been created 18:21:22 if we are expecting to nominate before nomination date then they can add dir along with candidacy 18:21:24 Nop 2025.1 is the newest 18:21:30 gmann: sure, but they would probably find that unorthodox, and probably do it wrong.. we just need to run a tox command and submit a change 18:21:44 fungi: +1 18:21:58 which is still ok as nomination before nomination is not a regular thing and it is not forced too right 18:22:36 we're already running the election for a longer period this time, ie. 6 weeks 18:22:42 that is why nomination start date is so that election official can plan their work accordingly. if we ask election officials to add these extra things (plan pre-nomination) in their plate it might be extra expectation 18:23:14 especially considering that we have been struggling to attract more election officials since long 18:23:24 I feel adding more extra thing to them is not good idea 18:23:30 hmm, i'd hope not.. lets just throw in a bunch of directories at once 18:23:34 accepting nominations earlier is OK to me but I would want to be sure that people shouldn't expect election official reviews *before* the official starting date 18:23:43 bauzas: yes, there's no such expectation 18:23:52 CI for instance, would fail because the dates are configured 18:23:55 is this a written statement somewhere? 18:24:04 aha I see 18:24:05 gouthamr: early nomination needs to be rechecked, reviewed, and maybe rebase so it is ofcourse more work than just preparing the dir 18:24:52 yeah 18:25:14 hmmm, it sounds like you two are reneging on our earlier discussion that this was a good thing :) the aim here is to prevent leaderless projects because of long holiday weeks during the election cycle 18:25:15 in the past, have we seen occurrences of nomination patches being open earlier ? 18:25:32 IMO, we should plan early-nomination things when we see there is cases who require it (anyong going on vacation during nominations 2 weeks or so). otherwise extending nomination period to 2 weeks is a wide window for them to add nomination on time 18:26:06 gouthamr: haven't we considered that specific holiday period by extending the nomination period ? 18:26:18 my only concern here is it add some extra work on election officials 18:26:36 we haven't extended the nomination period - the voting period increased to 3 weeks 18:26:57 gmann: that's my concern too 18:27:04 but is 2 weeks nomination period still short? 18:27:11 gouthamr: my bad, you're right 18:27:49 so, I see the problem now but my concern remains 18:27:51 though the nomination window is 2 weeks long 18:28:02 that wasn't an increase 18:28:16 yup, pardon my misunderstanding, my maths were wrong 18:28:24 at least not in change 938782 18:28:25 In the past folks have missed nominations 18:28:25 here we are finalizing some dates for election officials to work on but asking them to do tasks before those dates. which might impact their plan 18:28:54 spotz[m]: after we extended it from 1 week to 2 weeks? 18:29:46 we still (and always wil, i think) have missed nominations 18:29:48 I know when it was 1 week, we had cases of missing nomination but after we extended it to 2 weeks I am not sure the example who missed because 2 weeks is short. reason of missing might be something other 18:29:50 tbc, say we merge the directory patch now, this would avoid rebases but not rechecks for people nominating themselves, right? 18:30:13 yes 18:30:26 this wouldn't be a problem as anyone can request a recheck 18:30:55 People just forget:( How many late volunteers do we get every election? Voting I think tends to be more apathy then I forgot or needed longer 18:31:05 for example, election officials could only start to review that nomination patch after they recheck the nomination patches on the day the nomination period starts 18:32:12 #link https://opendev.org/openstack/election#preparation (Election prep) 18:32:59 this thing states, "As early as possible but at least a month before election starts" ... don't think we'd be doing anything new 18:33:23 OK, then I take the point to discuss that with the officials 18:33:27 the biggest issue i see with early nominations is that it's not obvious when ci would later reject the change and the nominee isn't around to address feedback (fix their foundation profile, et cetera) 18:33:49 this is the election official planning for this election 18:33:51 #link https://etherpad.opendev.org/p/TC_PTL_Elections2025.2F 18:34:09 If I'm understanding what everyone is typing and with past EO knowledge, the only thing the EOs need to do early is create the directories and maybe send a single email? 18:34:14 gmann: thank you, lost that link myself :) 18:34:21 and I think early nomination will impact their plan or they need to change some tasks 18:35:08 i think the etherpad is missing the early election stuff 18:35:09 which is what my concern is. if we want early nomination then I will suggest to do it from next election with election official proper planning 18:35:12 I can propose that directory patch if that helps 18:36:10 but in that case, if there's advance planning that makes early nominations desirable and communication will be done far enough in advance, the nomination period could also just be made officially longer 18:36:37 gmann: makes sense.. we're not requiring it - this is an earnest effort to avoid people missing the nomination window - lets see how it pans out after bauzas follows up.. 18:36:46 exactly, I will prefer that to extend nomination period for 3 or 4 weeks than unnoticed early-nomination practice 18:37:11 gouthamr: sure 18:37:39 I'm just working on a patch, I'll follow up with slaweq and ianychoi 18:37:47 good stuff, thanks bauzas 18:37:51 but early-nomination is not just about dir, it is much more. communication/announcement etc 18:37:53 anything else about this AI? 18:38:45 - 18:38:45 just a reminder that there's an alternative option for people who know they won't be around for nominations: ask someone else to push the patch on their behalg 18:38:48 behalf 18:39:02 not meaning to rush this, but, we've to get to the other topics on our agenda 18:39:11 (that's been done in the past) 18:39:16 i never knew that 18:39:33 * bauzas remembers when he had to run for the PTL election on August every year and organizing his life off the keyboard around the election dates 18:39:33 always thought we required "self nomination" 18:39:35 that's why we stopped keying on the committer address in the change 18:39:48 Yeah you don't have to self nominate but I assume you need to confirm the nomination 18:39:59 * bauzas would have appreciated to know he was able to propose his patch earlier than when he was on PTO 18:39:59 we've had nominees post their nomination to the mailing list and arrange for someone else to push a patch for them 18:40:36 spotz[m]: ++ yeah 18:40:45 okay, #TIL 18:40:58 thanks for the discussion, and lets follow up outside this meeting 18:41:05 next AI: 18:41:08 mirroring DockerHub images to Quay to avoid rate limits 18:41:24 Sylvain Bauza proposed openstack/election master: Create candidates/2025.2 placeholder directories https://review.opendev.org/c/openstack/election/+/939750 18:41:31 fungi: clarkb: i think this was something you wanted to discuss at the opendev meeting 18:42:12 any updates regarding this? 18:42:22 we did, i don't think we reached any agreement on how we would evaluate proposals to add images to the opendevmirror org on quay, though clarkb can correct me if i'm wrong 18:42:49 though we did have a fair amount of luck switching some of our builds/jobs over to use things we've started auto-mirroring to quay 18:42:49 ya I think we're trying to see how it grows organically. I'm happy to mirror things under that namespace that are generic enough to be widely applicable. 18:43:03 and yes it seems to have helped quite a bit for things that have switched over 18:43:22 basically we wouldn't mirror kolla images there. Kolla should set up their own mirror. But we are mirroring python and httpd and mariadb imges 18:43:42 we have also seen image updates fail 18:44:06 which isn't unexecpted due to the rate limits. But it is worth noting as a limitation of the system. If you need things to update quickly it may not be the best choice 18:44:09 for anything we're already mirroring to opendevmirror, i expect projects could choose to switch their jobs to use those rather than duplicating that effort 18:44:17 sounds reasonable.. maybe project teams need this information somewhere? or would they already know to contact #opendev to set this up 18:44:35 I suspect most of the groups that have had these problems with docker hub have already reached out 18:44:39 for now definitely ask in #opendev or attend weekly meetings 18:44:41 we've talked to an umber of people already 18:44:48 ++ 18:45:21 it's still definitely evolving 18:45:40 thank you for working on this; hoping the job instability subsides over time with this 18:45:56 anything else to share wrt this AI? 18:46:02 not from me 18:46:20 nor me 18:46:27 ty 18:46:31 next one: Review/merge the eventlet goal proposal 18:46:43 this was done \o/ 18:47:11 * gouthamr hopes the actual migration is just as easy 18:47:31 /jk 18:47:48 next one, next steps for reactivating the Freezer project 18:48:09 so I'm having an issue with launchpad right now 18:48:23 noonedeadpunk: i'm looking for more reviews on the retirement of freezer-dr 18:48:31 there was a ML some time ago https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/7PD7TVDLSHVXL7O7HFDVQXAZVW2EUV4G/ 18:48:33 aha 18:48:37 ok, that is needed as well 18:48:45 #link https://review.opendev.org/c/openstack/governance/+/938183 (Retire Freezer DR) 18:48:47 but actually it's also realted 18:49:04 as I wanted to move from storyboard to launchpad, which requires governance patch 18:49:06 #link https://review.opendev.org/c/openstack/governance/+/938938/ (Remove Freezer from inactive state) 18:49:20 ah, sure 18:49:32 but was wondering if I should push governance patch before we recover access to launchpad, or we can do in parallel? 18:49:36 I think it was to allow freezer release for 2025.1 even it is inactive till m-2 of this release 18:49:39 As I don't expect any reply to ML 18:49:45 and resolution to do that? 18:49:58 that yes - I will push tomorrow morning first thing 18:50:11 noonedeadpunk: I think LP things can be setup in parallel 18:50:33 as I guess we'd need LP admins to intervene 18:50:50 noonedeadpunk: I can do that. we can discuss after meeting 18:50:55 ++ 18:51:18 unless you want to create a new openstack-freezer project on lp instead of reusing the old freezer project there 18:51:28 noonedeadpunk: this can be used as an example: https://answers.launchpad.net/launchpad/+question/819336 18:52:03 gouthamr: thanks! 18:52:07 but yes, the lp admins would be the next point of escalation if the old driver/maintainer group admins aren't responsive 18:52:11 and maybe Billy Olsen can put in a word again, to expedite 18:53:12 ty for working on this noonedeadpunk, anything else for this AI? 18:53:15 I wonder if we should generaly go through launchpad projects and see if openstack-admins is present everywhere 18:53:24 YES 18:53:36 as at scale this somehow becomes weird 18:53:41 i thought to do this in my copius free time, just slacking at the moment :/ 18:54:03 we I had pretty same issue with OSA as well back in the days, except there were quite some active ppl around... 18:54:42 (as admins) 18:54:56 the incubation workflow effectively created this problem, since project initiators were encouraged to set up things in lp and then would forget to switch maintainership over to openstack later once accepted 18:55:00 (but not active as core reviewers anymore) 18:55:26 fungi: true, we required individuals to own the teams iirc 18:55:28 maybe we can set our process to check for this 18:55:46 (not sure if there's gonna be any more new projects though) 18:56:05 but it is extremely fair note about root cause 18:56:42 * gouthamr woah we're at :56?! 18:57:11 good convos today! 18:57:23 this has been a great discussion so far - we're catching up on AIs, that's always productive 18:57:34 we have one other topic 18:57:43 besides the regular checks 18:57:47 lets get into that: 18:57:49 #topic DPL model reset (gmann) 18:57:55 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/SKLDVCTLO2UBGWXJTRB7VTJHBODJBPOB/ 18:58:04 not sure we have enough time to discuss it but 18:58:23 we have 5 project in DPL model and freezer already opted in for DPL so 4 remaining. 18:58:38 we need to take decision on those before election nomination start date which is Feb 5 18:59:15 #link https://review.opendev.org/q/hashtag:%22dpl-reset%22+(status:open%20OR%20status:merged) 18:59:20 as per process they need to move to PTL model and goes for election if project team does not opt-in explicitly to continue the DPL mdoel for next cycle 18:59:44 do we have any feedback from the communities ? only watcher did afaicr 19:00:03 it occurs to me that there's no "governance liaison" in dpl, so it's unclear whose responsibility it is to propose the renewal change 19:00:09 yeah, freezer and watcher (not all liaison ) responded 19:00:25 I quite appreciate the fact that DPL doesn't span over multiple releases 19:00:39 every release, there is a need to opt into it 19:00:41 fungi: we have TC liaison there who will reset the leadership and all liaison can -1 there to continue iut 19:00:44 #link https://review.opendev.org/q/hashtag:%22dpl-reset%22+(status:open+OR+status:merged+OR+status:abandoned) 19:01:13 we're at the hour.. gmann can we bump that email sometime this week? 19:01:20 bauzas: we discussed it to do every 2 cycle but we agreed to be every cycle 19:01:28 gouthamr: sure, i can do today 19:01:33 thank you.. 19:01:35 ++ 19:01:45 we don't have time for open discussion today 19:01:57 but that's the after party post this meeting 19:02:04 thank you all for attending 19:02:10 and for the discussion! 19:02:17 #endmeeting