15:00:03 <gmann> #startmeeting tc
15:00:03 <opendevmeet> Meeting started Thu Sep 29 15:00:03 2022 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:03 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:03 <opendevmeet> The meeting name has been set to 'tc'
15:00:06 <gmann> #topic Roll call
15:00:08 <JayF> o/
15:00:09 <gmann> o/
15:00:40 <slaweq> gmann I have today another meeting at the same time as our tc meeting so I will be just lurking here for first 30 minutes
15:00:49 <gmann> slaweq: ack. thanks
15:00:54 <jungleboyj> o/
15:01:00 <slaweq> o/
15:01:01 <gmann> today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
15:01:10 <jungleboyj> As a lurker I guess. :-)
15:01:32 <knikolla[m]> o/
15:02:01 <gmann> jungleboyj: good to have you in meetings
15:02:10 <noonedeadpunk> o/
15:02:18 <spotz_> o/
15:02:52 <gmann> let's start
15:02:57 <gmann> #topic Follow up on past action items
15:03:00 <rosmaita> o/
15:03:09 <gmann> there is one action item
15:03:10 <gmann> JayF to send the ics file on TC PTG ML thread
15:03:22 <JayF> There is no TC PTG ML thread to send it to, afaict :)
15:03:48 <gmann> JayF: this one you can reply to #link https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030575.html
15:04:09 <JayF> ack; got it, I'll take care of that this morning
15:04:18 <gmann> perfect, thanks JayF
15:04:29 <gmann> #topic Gate health check
15:04:37 <gmann> any news on gate
15:05:06 <gmann> devstack and grenade setup for 2023.1 cycle is almost done #link https://review.opendev.org/q/topic:qa-zed-release
15:05:10 <slaweq> nothing from me
15:05:29 <gmann> from failure side, I have not noticed any more frequent one
15:06:11 <slaweq> starting 2023.1 cycle we should have "skip release" grenade jobs in projects, right?
15:06:38 <gmann> yes, we have setup that in grenade side
15:06:59 <slaweq> maybe we should remind teams that they should ask such jobs in their queues? wdyt?
15:07:03 <gmann> #link https://review.opendev.org/c/openstack/grenade/+/859499/2/.zuul.yaml#378
15:07:24 <gmann> many projects but may be 5-6 have those already but yes we should remind them
15:07:51 <slaweq> I can send email about it
15:07:56 <gmann> slaweq: thanks.
15:08:47 <gmann> #action slaweq to send email to projects on openstack-discuss ML about add the grenade-skip-level (or prepare project specific job using this base job) in their gate
15:09:09 <gmann> projects can use this as base job like done in manila project
15:09:35 <gmann> #link https://github.com/openstack/manila/blob/486289d27ee6b3892c603bd75ab447f022d25d13/zuul.d/grenade-jobs.yaml#L95
15:09:42 <noonedeadpunk> gmann: jsut to ensure I got it right - basically upgrade job from Y to A
15:09:44 <gmann> this needs to be updated. I will do after meeting
15:09:56 <gmann> noonedeadpunk: yes, stable/yoga to current master
15:11:08 <gmann> I think other than greanade in-tree supported projects, manila is first one to setup the job till now
15:11:27 <rosmaita> but to be clear, we don't actually support skip-release-upgrades until 2023.1, because that is our first 'tick' release
15:11:28 <gmann> also we need to make sure it does not run on zed gate
15:12:13 <gmann> rosmaita: so 2023.1 we will say first SLURP right? means it can be upgraded from  stable/yoga and stable/zed both ?
15:12:21 <gmann> that is what i remember
15:12:36 <arne_wiebalck> o/
15:12:38 <slaweq> so those skip-level job can be non-voting in 2023.1 cycle but I think projects should start adding it to see how things works/not works for them
15:13:10 <rosmaita> right, 2023.1 is supposed to be designed to be able to go directly to 2024.1
15:13:12 <gmann> mentioned here too #link https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html#example-sequence
15:14:19 <rosmaita> right, so A (or 2023.1) is the first SLURP, which i thought meant you will be able to go from 2023.1 to 2024.1, not that you should be able to upgrade to 2023.1 from yoga
15:14:22 <gmann> "Our letter-based release naming scheme is about to wrap back around to A, so the proposal is that the “new A” release be the first one where we enforce this scheme. Y->A should be a “dress rehearsal” where we have the jobs enabled to help smoke out any issues, but where hard guarantees are not yet made."
15:14:29 <gmann> rosmaita: you are right
15:14:34 <rosmaita> ok, cool
15:14:42 <rosmaita> (just wanted to be sure)
15:14:43 <noonedeadpunk> +1
15:14:57 <noonedeadpunk> make sense to me - was just double checking I remember it right
15:15:01 <gmann> let's ask project to add jobs anyways
15:15:05 <gmann> thanks
15:15:07 <knikolla[m]> makes sense.
15:15:15 <jungleboyj> ++
15:15:18 <rosmaita> yes, the "dress rehearsal" is a good metaphor for this
15:15:23 <JayF> It's not a dress rehersal if we don't actually reherse, so I don't think that it's a rehersal changes any actions.
15:15:27 <gmann> slaweq: let's ask and if any project facing issue then they can keep it non voting but let's tell to make it voting
15:15:41 <slaweq> ++
15:15:59 <knikolla[m]> i guess more of a canary
15:16:11 <gmann> stable/wallaby to stable/yoga went pretty well so may be Y->2023.1 will also
15:16:37 <JayF> I know many operators in practice have been skipping releases frequently. It'll be interesting to see if CI unearths anything that they haven't exposed.
15:17:11 <gmann> yeah that is our intension but let's see how our testing is on upgrade
15:17:25 <gmann> and will give opportunity to extend it
15:17:38 <jungleboyj> *fingers crossed*
15:18:14 <gmann> ok, moving next
15:18:15 <gmann> Bare 'recheck' state
15:18:25 <gmann> #link https://etherpad.opendev.org/p/recheck-weekly-summary
15:18:30 <gmann> slaweq: go ahead please
15:19:49 <slaweq> I don't have much to say today
15:19:55 <slaweq> I contacted few projects last week
15:20:02 <gmann> +1
15:20:06 <slaweq> lets see if things for them will improve now
15:20:37 <gmann> yeah, it is getting noticed. tacker project contacted me to get more clarification on it and they understand and will take action
15:21:00 <gmann> thanks slaweq for driving this and helping to save the infra resources
15:21:03 <JayF> Can the tool used to generate these spit out specific patch URLs? I'm mainly curious (with my PTL hat on) who the 'stragglers' are in Ironic that are not yet putting reasons for rechecks
15:21:25 <JayF> and if that tool exists, we can potentially offer it to other project leaders to enable them to chat about specific instances
15:22:02 <gmann> one is this list https://etherpad.opendev.org/p/recheck-weekly-summary#L21
15:22:19 <gmann> I hope that is bare recheck one only
15:22:33 <slaweq> JayF scripts are here https://github.com/slawqo/rechecks-stats
15:22:56 <JayF> ack slaweq, will look into it thanks :D
15:23:02 <slaweq> yw
15:23:10 <gmann> thanks
15:23:18 <gmann> anything else on bare recheck?
15:23:24 <knikolla[m]> i noticed that someone auto-translated the latter half of that etherpad
15:23:46 <fungi> if you need it rolled back to an earlier state, let me know
15:23:58 <fungi> there's an admin api i can use to undo revisions
15:25:06 <gmann> ok
15:25:12 <gmann> Zuul config error
15:25:15 <gmann> #link https://etherpad.opendev.org/p/zuul-config-error-openstack
15:25:23 <gmann> we talked about it before meeting
15:25:41 <gmann> and we need more aggressive approach to get them fixes or fix them.
15:26:03 <gmann> knikolla[m] volunteer to drive this from TC side by taking to project lead/liaison or fixes them
15:26:06 <gmann> thanks knikolla[m] for that
15:26:25 <knikolla[m]> fungi: thanks. i looked at the revisions and doesn't seem necessary. the translation was appended, rather than replacing the content. weird.
15:26:26 <gmann> but I will suggest we as tc-members also can take some of the project and fix them
15:26:30 <gmann> like slaweq will do for neutron
15:26:46 <gmann> I volunteer to do for nova, qa, glance, and keystone
15:27:14 <gmann> please add your name in etherpad #link https://etherpad.opendev.org/p/zuul-config-error-openstack#L26
15:27:17 <JayF> I am surprised to see Ironic hits on that list; I'll ensure those are corrected.
15:27:21 <fungi> to restate what i suggested before the meeting, i recommend prioritizing maintained stable branches. for em branches you could take teams not fixing those as an indication they're ready for early eol
15:27:32 <gmann> JayF: cool, thanks
15:27:41 <knikolla[m]> fungi: ++
15:27:43 <clarkb> one common cause of these errors in the past has been project renames requested by openstack
15:27:49 <TheJulia> JayF: I think the ironic ones are branches I've long expected to be closed out
15:28:08 <JayF> TheJulia: I will likely propose at next Ironic meeting we EOL a bunch of stable branches
15:28:08 <TheJulia> jfyi
15:28:11 <clarkb> it would be a good idea for everyone requesting project renames to understand they have a little bit of legwork to complete the rename once gerrit is done
15:28:16 <gmann> yeah, it will unhide the EM branches gate status also if those are broken and unnoticed
15:28:30 <TheJulia> JayF: just do it :)
15:28:53 <gmann> clarkb: sure, let me it as explicit step in project-team-guide repo retirement process
15:29:11 <fungi> gmann: that's an excellent idea, thanks
15:30:05 <gmann> but let's take 2-3 projects by ourselves to fix these and we will 1. fix many projects 2. trigger/motivate other projects/contributors to do it
15:31:08 <gmann> #action gmann to add a separate step in repo rename process about fixing the renaming repo in zuul jobs across stable branches also
15:31:17 <gmann> anything else on zuul config error or gate heath ?
15:31:39 <clarkb> yseterday I updated one of the base job roles
15:32:07 <clarkb> the motivation was to speed up jobs that have a large number of required projects like those for OSA. Doesn't seem to have hurt anything and some jobs should be a few minutes quicker now
15:32:25 <gmann> nice
15:32:50 <clarkb> In general, there are some ansible traps that can increase the runtime of a job unnecessarily. Basically loops with large numbers of inputs where each loop iteration shouldn't be expensive so incurs ansible task overhead as the real only overhead
15:33:05 <clarkb> be on the lookout for those and if you have them in your jobs rewriting to avoid loops in ansible can speed things up quite a bit
15:33:07 <fungi> there was also a recent change to significantly speed up log archiving, right?
15:33:22 <clarkb> fungi: yes that was motivated by neutron jobs but really all devstack jobs were impacted
15:33:25 <fungi> (along the same lines)
15:33:36 <clarkb> it had the same underlying issue of needlessly expensive ansible loops.
15:33:47 <clarkb> Anyway this is more of a "if your jobs are slow this is somethign to look for" thing
15:34:07 <gmann> +1, thanks for improvement and updates clarkb
15:34:40 <gmann> #topic 2023.1 cycle PTG Planning
15:34:59 <gmann> we have etherpad ready to add the topics
15:35:00 <gmann> #link https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1
15:35:06 <gmann> #link https://etherpad.opendev.org/p/tc-2023-1-ptg
15:35:12 <gmann> with schedule information too
15:35:24 <gmann> and JayF will send the icals over ML too
15:35:46 <gmann> on operator-hour sessions, we have 7 projects booked till now
15:36:10 <gmann> I will send another reminder to projects sometime next week
15:36:39 <fungi> if anyone needs operator hour tracks created in ptgbot, feel free to ping me in #openinfra-events
15:36:43 <gmann> but feel free to reachout to projects you are contributing or in touch with to book it
15:37:26 <gmann> yeah
15:37:51 <fungi> (track creation/deletion is an admin operation, the rest should be pretty self-service though)
15:38:10 <gmann> yeah.
15:38:20 <gmann> anything else on PTG things for today?
15:39:13 <gmann> #topic 2023.1 cycle Technical Election & Leaderless projects
15:39:23 <gmann> Leaderless projects
15:39:29 <gmann> #link https://etherpad.opendev.org/p/2023.1-leaderless
15:39:51 <gmann> no special update on this but all the patches for PTL appointment is up for review, please provide your feedback there
15:40:35 <gmann> TC Chair election
15:40:48 <gmann> as you know we have TC chair election going on
15:41:12 <gmann> you might have received email for CIVS poll, JayF is handling the election process
15:41:37 <gmann> 1. please let JayF know if you have not received the email
15:41:51 <fungi> (after checking your junk/spam folder)
15:41:57 <gmann> +1
15:42:15 <spotz_> Everyone should be opt-in at this point:)
15:42:20 <gmann> 2. vote if not yet done. we do not need to wait until last day instead we can close it early once all members voted
15:42:35 <gmann> yeah opt-in is required
15:42:56 <jungleboyj> :-)
15:43:16 <gmann> and just to restate, once voting are closed. we will merge the winner nomination and abandon the other one
15:43:27 <rosmaita> thanks to gmann and knikolla[m] for making an election necessary!
15:43:46 <rosmaita> (i am not being sarcastic, i think it is a good thing)
15:43:57 <knikolla[m]> :)
15:44:04 <gmann> and in PTG we can discuss on how to make nomination/election more better/formal.
15:44:12 <gmann> +1, agree
15:45:05 <gmann> anything else on this?
15:45:14 <jungleboyj> +1  And also gmann thank you for putting your name in again.  All your leadership recently is GREATLY appreciated.
15:45:30 <gmann> thanks
15:45:49 <gmann> #topic Open Reviews
15:46:02 <gmann> one is this one #link https://review.opendev.org/c/openstack/governance/+/859464
15:46:03 <gmann> Dedicate Zed release to Ilya Etingof
15:46:19 <gmann> this is great idea and thanks iurygregory for the patch
15:46:26 <gmann> please review and cast your vote
15:46:34 <JayF> I'd like to thank fungi for suggesting that, and iurygregory for owning putting up the patch. Ilya Etingof was a valued member of the Ironic community and this is a deserving tribute.
15:47:00 <rosmaita> ++
15:47:07 <gmann> ++ true
15:47:17 <arne_wiebalck> JayF: ++
15:47:40 <spotz_> ++
15:47:51 <fungi> the 7 day waiting period for motions as described in the charter puts the earliest possible approval date right before the release, so merging it in a timely fashion will be good
15:48:12 <gmann> yeah
15:48:22 <jungleboyj> ++
15:48:30 <fungi> the feedback so far has been all in favor, so the foundation marketing crew are operating under the assumption it will merge on schedule
15:48:52 <fungi> as far as mentioning the dedication in press releases about the release, and such
15:49:08 <jungleboyj> One of the special things about this community.
15:49:09 <knikolla[m]> the majority voted, so setting a reminder for when the 7 days are up.
15:49:30 <knikolla[m]> jungleboyj: ++
15:49:44 <gmann> sure, I think 7 we can merge it but we will keep eyes on it
15:49:49 <gmann> 7th oct
15:50:01 <gmann> or may be 6th, i will check
15:50:12 <gmann> another patch to review is this #link https://review.opendev.org/c/openstack/governance/+/858690
15:50:14 <knikolla[m]> 4th
15:50:15 <fungi> charter says 7 calendar days, which would be october 4
15:50:48 <gmann> yeah, that is even better. I will run script to get it merge asap
15:51:02 <gmann> migrating the CI/CD jobs to ubuntu 22.04
15:51:06 <fungi> that's the day before the release, just to be clear
15:51:12 <gmann> it is in good shape now, thanks to noonedeadpunk for updating
15:51:19 <gmann> fungi: ack
15:51:59 <gmann> that is all from agenda, we have 9 min left if anyone has anything else to discuss
15:53:18 <gmann> our next meeting will be on 6th Oct and a video call
15:53:25 <JayF> Those nine minutes would be a great opportunity for the 4 folks who haven't voted to do so :)
15:53:32 <gmann> +1
15:53:34 <knikolla[m]> ++
15:53:50 <spotz_> ++:)
15:54:36 <gmann> let's vote if you have not done
15:54:44 <gmann> thanks everyone for joining, let's close the meeting
15:54:50 <gmann> #endmeeting