Thursday, 2022-05-19

*** ykarel_ is now known as ykarel04:51
*** pojadhav|afk is now known as pojadhav05:10
*** dasm|off is now known as dasm13:21
slaweqgmann: hi, I may be little bit late for the tc meeting today13:55
slaweqbut I should be there13:56
gmannslaweq: ack, thanks 14:31
gmanntc-members: meeting in 2 min from now14:58
gmann#startmeeting tc15:00
opendevmeetMeeting started Thu May 19 15:00:18 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'tc'15:00
gmann#topic Roll call15:00
gmanno/15:00
jungleboyjo/15:00
dansmitho/15:00
slaweqo/15:00
* slaweq is on time :)15:00
dpawliko/15:01
rosmaitao/15:01
arne_wiebalcko/15:01
gmannlet's start15:02
gmann#link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting15:02
gmann^^ today agenda15:02
gmann#topic Follow up on past action items15:02
gmannnone from previous meeting15:02
gmann#topic Gate health check15:03
gmannany news15:03
dansmithso there was something mentioned about my dbcounter thing breaking jammy,15:03
dansmithbut for reasons that make no sense and I haven't been able to repro locally15:03
gmannok, jammy jobs are made non voting now15:03
dansmithlike, pip complaints that the python-builtin module 'glob' is not available <-- makes no sense15:03
dansmithright15:03
gmannhumm15:04
dansmithother than that,15:04
dansmithI've got this proposed: https://review.opendev.org/c/openstack/devstack/+/83894715:04
dansmithwhich attempts to highlight perf regressions, although I think it's still up in the air whether or not it's worthwhile15:04
dansmithbut might be interesting to some15:04
gmann+1, this will be helpful 15:05
gmannI will review it15:05
dansmithalso sounds like a couple people are working gate stability fixes through, for instance resize and one other I forget at the moment15:05
gmannyeah, c9s again failing on detach volume things, which again is going to be fixed/workaround by making test SSH-able15:05
fungidns resolver startup race for fips jobs15:05
dansmithoh there's some tripleo c9s failure too I think15:05
dansmithrelated to libvirt and libvirt-python being broken in cs9 right?15:06
gmannI am trying to make all detach volume waiting for SSH-able server but not yet passing #link https://review.opendev.org/c/openstack/tempest/+/84224015:06
gmannyeah15:06
fungiat this point we're thinking we should probably change the systemd service unit for unbound so that the system doesn't consider itself fully "booted" until dns resolution works15:06
gmann#link http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028568.html15:07
gmannfungi: ok15:07
knikollao/15:08
gmannnot sure if ubuntu image with fips are available or when to be available. I am less hope of having c9s stable for this testing15:08
spotzo/15:08
gmannI think ade_lee will be keeping eyes on it15:08
gmannanything else on gate?15:09
dansmithnot from me15:09
ade_leeI definitely will 15:09
slaweqI still didn't had time to make script to count "naked" rechecks in projects15:09
fungigmann: ade_lee prodded the canonical folks about ubuntu fips options again this week, no response yet that i've seen15:09
gmannade_lee: thanks 15:09
slaweqbut I hope I will have more time for it next week15:09
slaweqso hopefully I will have some data on next meeting15:09
gmannslaweq: np!, thanks for working on it. 15:09
gmannfungi: I see. thanks for updates15:10
gmann#topic Zed cycle tracker checks15:10
gmann#link https://etherpad.opendev.org/p/tc-zed-tracker15:10
gmannwe have many item in progress and under review15:10
gmannbut please start the items not yet started. 15:11
gmannany updates or anything on zed tracker today ?15:11
arne_wiebalckI talked to Artem and Belmiro for the OSC.15:11
arne_wiebalckTo get an idea where things are.15:12
arne_wiebalckArtem is (ofc) very interested.15:12
gmannyeah15:12
arne_wiebalckHe mentioned Glance and Cinder (IIRC) as areas which need improvement.15:12
arne_wiebalckTo which I replied we have dansmith :-D15:12
slaweqI think that this https://review.opendev.org/c/openstack/governance/+/840856 is ready for review15:13
gmann:)15:13
jungleboyj:-)15:13
slaweqso if You have time, please take a look15:13
arne_wiebalckArtem has a fourm session on this at the summit.15:13
gmannslaweq: ack15:13
arne_wiebalck*forum15:13
arne_wiebalckI guess this will provide a good starting point what issues to tackle for the OSC.15:13
gmannarne_wiebalck: do you think this is ready for making goal now or pop-up team to get progress for glance, cinder? 15:13
arne_wiebalckgmann: how about we wait for the forum session to answer your question?15:14
gmannarne_wiebalck: ok, sounds good plan15:14
dansmitharne_wiebalck: I'm very pro-glance-being-better-on-osc, but I am in the vast minority :)15:14
gmannhumm15:15
gmannlet15:15
rosmaitacinder is supposed to meet with some OSC people either next week or during our first midcycle to discuss15:15
gmann+115:15
arne_wiebalckdansmith: would be good if the glance folks came to the forum session maybe?15:15
arne_wiebalckrosmaita: great15:15
gmannlet's see how it goes in forum and I think having it as a goal can push work more fast15:16
rosmaitathere are some big issues around how the OSC syntax does not make sense for some operations15:16
arne_wiebalckgmann: ++15:16
rosmaitaand to what extent that can be addressed15:16
gmannok15:17
gmannanything else on this?15:17
arne_wiebalcknot from me15:17
gmannarne_wiebalck: thanks for checking and start working on it.15:17
gmann#topic TC meeting with Board of Directors15:17
gmannone update on this. we have 45 min time to meet/present to board. 15:18
gmannI will prepare the slides as per the agenda discussed and share with you all for review/updates15:18
jungleboyj\o/15:18
dansmiththanks gmann :)15:18
jungleboyjGlad that we could reach an agreement on that.  Thank you gmann!15:18
fungihas that meeting been scheduled yet? and who is encouraged to attend?15:19
gmannit is in draft agenda but details will be soon on how to join and who all can join. non board member need RSVP I think15:19
gmannbtw who all are planning to be in-person in summit15:19
dansmithnot me15:20
gmannI am planning to join virtually 15:20
slaweqI will be in Berlin15:20
rosmaitanot me15:20
fungioh, wait, this is during the board meeting in berlin? i thought the project leaders weren't meeting with the board there15:20
jungleboyjI will not be physically or virtually.  I will be on a lake with little to no wifi.15:20
slaweqbut I didn't plan to go to the Board meeting on Monday15:20
fungiand TheJulia was scheduling alternative meeting options for project leadership15:20
gmannfungi: yeah TC+Board. 15:20
arne_wiebalckI will be in Berlin as well.15:21
dansmithfungi: there was much confusion, but I think the end result was a short meeting with the board during the board meeting, and then longer virtual openstack-specific call later15:21
gmannfungi: you mean project+board interaction? that is separate topic I have proposed 15:21
fungioh, thanks. so two separate meetings. openstack gets 45 minutes during the board meeting, and then there will be a separate openstack+board meeting as well15:22
jungleboyjdansmith:  That was my understanding as well.15:22
jungleboyjfungi:  Yes and I think that the separate meeting will be one or more virtual meetings 15:22
knikollai will be in Berlin and on monday as well15:22
fungibut other projects will not have an opportunity to meet with the board in berlin, only openstack?15:23
gmannfungi: no, 45 min OpenStack+Board. other one is in board formal meeting on topic "Open Infra project+board interaction"15:23
spotzI'll be in Berlin15:23
gmannfungi: TheJulia is talking to other projects15:23
gmannso arne_wiebalck slaweq spotz knikolla will be there15:23
fungiyeah, i've been in those conversations. just making sure i understand that teh other projects aren't being handled the same as openstack this time15:24
slaweqgmann should I then plan to be on the meeting with Board on Monday?15:24
gmannlet board schedule comes out. it is still in draft for other projects or so15:24
dansmithfungi: I don't think there's any special treatment going on here15:24
fungii think it wasn't clearly communicated to other projects that only openstack leadership would be participating in the board meeting15:24
gmannfungi: yeah. its same for everyone. 15:24
dansmithfungi: there was definitely confusion about the different plan this time and the other projects hadn't (last I heard) expressed a need/desire15:24
arne_wiebalckI will be travelling on Monday (the TC/board meeting arrangements were made somewhat late relative to travel organisation so I did not take this into account)15:25
gmannyes, few have not responded yet may be. but TheJulia is asking to all proejcts15:25
gmannarne_wiebalck: ack15:25
arne_wiebalckgmann: at which time is the meeting?15:25
* arne_wiebalck could probably look this up ...15:26
gmannanyways let baord schedule comes out and how other projects are planning 15:26
fungithe communications i was in on indicated that the board of directors didn't have time to meet with project leadership in berlin and were interested in setting up separate meetings15:26
gmannarne_wiebalck: 9am -5 pm local time but with two part15:26
gmannanything else on this topic?15:26
fungiso openstack being involved in the board meeting is definitely not consistent with what was communicated, hence my confusion15:26
dansmithfungi: there was much confusion15:27
arne_wiebalckgmann: thanks!15:27
gmannfungi: yeah those were all confusion but we are checking with all projetcs15:27
fungithanks for confirming. i'll try to follow up with TheJulia to get a clearer explanation15:27
gmann#topic New ELK service dashboard: e-r service15:27
gmanndpawlik: any updates on this?15:27
slaweqI'm not sure if dpawlik is still there15:28
slaweqbut he told me that he didn't make anything new15:28
gmannok. thanks for updates15:28
slaweqand that dasm is working on e-r 15:28
gmanncool15:29
slaweqbut I don't have more details about it15:29
gmann#topic 'SLURP' as release cadence terminology15:29
gmannso SLURP is agreed name and I have proposed patch to change name in resolution #link #link 15:29
gmann#link https://review.opendev.org/c/openstack/governance/+/84035415:29
gmannplease review that15:29
gmannrelease notes part as discussed will be handled by rosmaita 15:30
rosmaitai will have a patch up about that ... soon15:30
gmanncool, thanks 15:30
gmannanything else on this?15:30
gmann#topic Use release number or name in development process/cycle15:31
gmannelodilles: ttx ping15:31
elodilleso/15:31
gmannwe agreed to handover the release name process to Foundation and TC will not be involved in that15:31
gmannso no question on this part15:32
jungleboyj++15:32
gmannbut while proposing it documentation, another part came up how to use name/number in developement cycle15:32
gmannlike release page, schedule, automated tooling etc15:33
fungibranch names15:33
gmannI have proposed 3 option for this #link https://review.opendev.org/c/openstack/governance/+/841800/2/reference/release-naming.rst#3615:33
gmannyeah, branch name15:33
gmannand release team also discussed it in their meeting15:33
elodillesin rel-mgmt weekly meetings the milestone name and branch name came up15:33
gmannrelease page title can be both "OpenStack 2023.1 AA"15:34
elodilles++15:34
gmannbut milestone and especially branch name should be number? 15:34
elodilleswe discussed that milestone name is more clear with name15:35
gmannand so other automated tooling, dir structure in spec repo etc15:35
elodillese.g. aardvark-1 compared to 2023.1-1 milestone15:35
gmannMy thought was use name only in marketing side15:35
fungithe primary concern being that 2023.1-1 might make consumers think 2023.1 is already released15:35
gmannand in developement process during or at the release we use number15:36
rosmaitano, i think the idea was that the community likes using the names15:36
slaweqmaybe something like 2023.1-m115:36
gmann+1, 2023.1-m1 is more clear15:36
gmannrosmaita: that is my concern, if we continue using name in everywhere then how number will be communicated, they will be just go un-notice 15:37
rosmaitai thought the problem we were trying to solve was that while names are fun, it was no longer fun to try to come up with names15:37
dansmithwell, right now the version numbers are more confusing that useful, so switching to the new format and promoting them to more wide use would be good IMHO15:38
dansmithespecially in preparation for the foundation throwing up their hands in two years and saying "meh names are too hard" :P15:38
arne_wiebalckdansmith: :-D15:38
gmannyeah, promoting numbers has long term benefits 15:38
rosmaitai thought we were keeping the confusing individual project version numbering?15:38
jungleboyj:-)15:38
dansmithrosmaita: isn't that the whole point of the unified date versioning?15:39
gmannrosmaita: yes, they stay same15:39
dansmithso get everyone on the same thing?15:39
dansmithoh?15:39
rosmaitadansmith: see^^15:39
dansmiththen I'm very confused15:39
gmannno change in number schema what belmiro proposed and we all agreed 15:39
rosmaitabelmiro's original update specifically said ^^15:39
dansmithokay I totes missed that15:39
rosmaitamy impression was that the point was we will have Austin and Aardvark and need to know which is first15:40
gmann#link https://governance.openstack.org/tc/reference/release-naming.html#release-identification15:40
rosmaitaso we will have 2023.1 Aardvark15:40
gmannrosmaita: yeah that is there till we were ok with name also15:40
rosmaitaright, and i thought we were revising because we couldn't come up with a good naming process15:41
gmannas name are moving towards the marketing usage we should just use the number and name where we need more market things15:41
rosmaitabut that problem is now solved15:41
rosmaitai think we continue to use both as long as we have them both15:41
gmannrosmaita: so even with '2023.1 Aardvark' what is your idea on branch, release miletsone, spec dir side?15:41
dansmithwhere on there does it say the project versions stay the same?15:41
gmannwe cannot use both there, it should be one right?15:42
rosmaitanot there it's in the resolution15:42
dansmithokay15:42
rosmaitasounds like release team prefers name for milestone15:42
gmannstable/2023.1 or stable/AA or stable/2023.1.AA ?15:43
elodillesrosmaita: ++15:43
rosmaitaand we already have the branch tooling set up around names15:43
elodillesrosmaita: ++ :)15:43
rosmaitaand we'll never have two of the same beginning letter in the stable branches15:43
gmannthat is what changes are proposed and we need to change tooling also15:43
rosmaitabecause we delete eol branches15:43
slaweqso I will ask differently - do we really need that version numbers? If we are going to use name everywhere like it is currently15:44
gmannso just drop the number things as we are not using them anywhere than just in TC release-naming-process-page15:44
gmannslaweq: exactly 15:44
rosmaitathey will probably be used elsewhere15:44
gmannif we are not changing the implementation then there is no use of number15:44
jungleboyjI feel like we have just gone in a circle.15:44
gmannelsewhere where?15:45
slaweqjungleboyj++15:45
rosmaitalike announcements, "openstack releases 2023.1 Aardvark"15:45
rosmaitai missed where the tooling discussion happened, i guess15:45
slaweqbut at least name will not be choosen by TC anymore, and that's basically only change I think15:45
rosmaitaslaweq: that was my understanding15:46
gmannI think our main purpose for number is to give operator, user start knowing openstack release by number15:46
slaweqwhich IMHO is also good if that's what is prefered15:46
gmannrosmaita: you mean use name everywhere and number only in marketing ?15:46
rosmaitai thought it was for assisting them15:46
fungirosmaita: release tooling was discussed in the release meeting last friday15:46
fungi#link https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-05-13-14.00.log.html#l-4115:47
rosmaitayeah, but i am on the tc not the release team15:47
gmannI think we need to first decide or re-decide that we want OpenStack release to be primarily identified by NAME or NUMBER ?15:48
spotzName:)15:48
gmannrosmaita: we have not discussed in TC and just said Number as primary identifier 15:48
gmannspotz: then why we agreed on number in release process?15:49
gmannrelease name process15:49
fungirosmaita: the release managers manage the release tooling/automation, so release tooling changes get discussed in the release meeting15:49
fungiand then raised with the tc in the tc meeting15:50
gmannthis section explain why we need NUMBER #link https://governance.openstack.org/tc/reference/release-naming.html#release-identification15:50
spotzgmann I've been arguing for name all along. And there's 2 ways to think of the primary identifier, what everyone calls it and what's in the systems15:50
gmannIMO, if we are keeping name as it is then we just remove the Number things as it will be un-used and un-notice15:50
gmannspotz: you +1 on release number things #link https://review.opendev.org/c/openstack/governance/+/82956315:51
dansmithto be honest, the addition of the number if we're not moving projects to that seems like we've just added another disjoint version number.. it was mentioned in the commit and in the comments on the last PS,15:51
dansmithbut it really (really) wasn't what I was thinking we were doing15:51
jungleboyjBut, in the page you reference above it says that we need the number as it being the 'A' release is ambiguous given that we are on our second iteration through the alphabet.15:51
slaweqI think that even if we will be using both, like e.g. AArdvark 2023.1 then everyone will in practice use only Aardvark15:52
rosmaitaOK, so where that page says "The release identification schema doesn’t replace the release name. It’s just an unambiguous way to identify OpenStack releases.", what has changed?15:52
spotzIf that's the direction we were going I supported it, but that patch is WAY behind our more recent discussions15:52
dansmithmentioned in the commit *message* I should say,15:53
dansmithbut not on the actual doc we were reviewing15:53
jungleboyjI don't have a problem with adding the 2023.1 designation.  I see its usefulness.15:53
slaweqjungleboyj: totally agree15:53
gmannso we are moving back to ground because it is hard/not-prefered to use number in release miletsone and stable branch? 15:55
ttxif keeping the name anywhere is going to prevent people from fully switching to numbers, that tells a bit about how much humans prefer to communicate using words :)15:55
ttx(but I'll shut up)15:55
rosmaitattx: ++15:55
gmanndansmith: even we remove the projects versions things which is separate discussion though, I do not think we agreeing on what to use number of name15:55
jungleboyj:-)15:55
spotzttx +infinity:)15:56
dansmithgmann: right, but it informs my opinion on how important it is to use another number with the name15:56
gmannttx: it could be other way around too :) if number were used then switching to name could be in same boat15:56
dansmithgmann: and I'm sorry for apparently reading that doc with a totally different interpretation.. my bad apparently15:56
dansmithttx: fwiw, I refer to ubuntu releases based on their number because it's so much easier to know the order and age15:57
dansmithI can sometimes remember the lts release names, but never the intermediates15:57
slaweqdansmith++15:57
gmannyeah, both have their own pros and cons. numbers give is more time-relation to release15:58
dansmithlike I can look at my system still running 12.04 and feel the shame15:58
slaweqI think that people just get used to names already and that's why they will not switch to numbers if name will still be used everywhere15:58
gmannok 2 min left and I think we need re-discuss the naming/numbering things as we are back to ground on this15:58
jungleboyj:-)  Less shame in keeping a Bionic Beaver around?  :-)15:58
slaweq:D15:59
dansmithjohnsom: I definitely don't remember the animal, ever.. only the adjective.. good point15:59
dansmither, jungleboyj ^15:59
jungleboyj:-)15:59
gmannshould we meet on call to figure that out?15:59
gmannadhoc meeitng?15:59
rosmaitai think the other thing we need to address is what we have asked the foundation to do exactly16:00
dansmithyeah, I think there has been a lot of change since we had all this discussion initially, so we might want to have a specific voice call about it16:00
rosmaitai thought we wanted them to come up with a name following our criteria16:00
ttxdansmith: sure -- and yet they use the name during the development cycle and in the branch names :)16:00
gmann? that is clear right. they will handle the name16:00
jungleboyjgmann:  I thought so.16:00
rosmaitayeah, but following alphabetical ordering? 10 char limit? no emojis?16:00
gmannrosmaita: come up with name as per the criteria they want16:01
ttxno emojis? That's it, I quit16:01
jungleboyjI thought we had agreed to not remove the names.  So, I think the question is whether we make the numbering more visible.16:01
* jungleboyj laughs at ttx16:01
gmannjungleboyj: yeah16:01
rosmaitano, i thought they could use whatever *process* they want to find a name that meets our criteria16:01
jungleboyjrosmaita: ++  16:01
jungleboyjThey are going to work on figuring out the naming process.16:02
gmannrosmaita: if they want to meet our criteria then what change made? just moving execution form TC to Foudnation. I think we said let foundation to come up with name and no TC involvement16:02
gmannyeah, they can pick our or their own16:02
jungleboyjgmann: ++16:02
rosmaitathe change is that they will handle finding a name that meets our criteria16:02
gmannanyways we are going out of time. I will schedule a voice all sometime next week on this16:02
rosmaitalike, we do expect them to keep the alphabetical ordering, right?16:03
jungleboyjrosmaita: ++16:03
jungleboyjgmann: ++16:03
gmannrosmaita: no, whatever they like to name :)16:03
slaweqsorry but I have to leave now. I'm ok with adhoc meeting to discuss that once again if it will be needed16:03
slaweqo/16:03
gmannrosmaita: anyways we will discuss that too16:03
rosmaitaok16:03
gmann#topic Open Reviews16:03
gmann#link https://review.opendev.org/q/projects:openstack/governance+is:open16:03
gmann^^ please review these, few of them are ready to vote16:03
gmann#link https://review.opendev.org/c/openstack/governance/+/84035416:04
gmann#link https://review.opendev.org/c/openstack/governance/+/84036316:04
gmann#action gmann to schedule 'release name things' discussion call *again*16:05
gmannlet's close meeting.16:05
gmannthanks everyone for joining16:05
jungleboyjThanks!16:05
gmann#endmeeting16:05
opendevmeetMeeting ended Thu May 19 16:05:26 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:05
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-19-15.00.html16:05
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-19-15.00.txt16:05
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-19-15.00.log.html16:05
clarkbI had one thing I wanted to call out if there was time which is https://lists.zuul-ci.org/pipermail/zuul-discuss/2022-May/001801.html16:05
clarkbbasically some zuul config syntax will be removed in the next release. I need to run the script mentioned in that email and send email to openstack-discuss with a list of offenders16:05
clarkbbtu we know that openstack does a fair bit of this so expect the list to be non empty16:06
clarkbwanted to call it out here so that the project at a high level was aware16:06
fungithere are a lot of projects specifying named queues in their configuration which will cease to be able to test or merge changes until they fix their configs16:06
gmann'list of offenders'? I think it is more of moving to new things as old one are gone :) or we were using something not supposed to use? 16:07
gmannbut +1 on sending the list of affected things in ML16:07
clarkbwell its the sort of change that will break CI for those projects if they aren't fixed so I don't want it to end up like the existing zuul errors list. Which is down to 64 but not 016:08
gmannclarkb: honestly saying, I am not sure how many of projects contributors or us are in zuul ML to get to know these deprecation things and to fix in advance. 16:11
fungiyeah, and hopefully a lot of projects are already doing it the new way (the old way was deprecated 14 months ago), but it's also likely some have added queues and just cargo-culted the deprecated syntax from older projects too16:11
gmannwe are getting it to know once it is going to be removed or error in CI16:11
clarkbgmann: yes, that is why I'm brining it up and planning to send emil about it today once I run the script.16:11
fungigmann: clarkb reads the zuul-discuss ml and brings it up with the tc before producing a list and asking projects to fix their configs16:11
gmannhaving them in openstack-disucss ML can eb helpful to fix these in advance16:11
fungiseems like that was the plan16:11
gmannclarkb: fungi but this time is breaking change not deprecation and you have time to fix things before next release or so?16:12
fungiwould you prefer he send those announcements to the ml before he lets the tc know in irc?16:12
gmannfungi: clarkb I am confused, so it is deprecation time and expect project to move to new things or is it going to break them now if they do nt fix?16:13
fungihe's mentioning it here the same week the removal plan was announced16:13
fungiso that things can be fixed in advance16:13
gmannok, when is removal plan?16:13
fungiwhen zuul 7.0.0 is released is when they'll be removed16:13
clarkband we probably have at least a month before that happens. But there isn't a fixed date for that release yet16:14
clarkb(Zuul doesn't release on a calendar schedule)16:14
gmanncool, I thought we removed and things broke16:14
gmannclarkb: +116:14
gmannsounds good plan16:14
funginope, the goal is to take care of this before things break16:14
gmann+1, thanks16:14
gmannsorry i misread that. 'release name horror story' again occupied my mind :)16:15
fungithe good news is that it's a very simple configuration change projects need to merge16:15
gmannok16:15
clarkbyes its a straightforward fix, but so are many of those 64 existing zuul cofnig errors :/16:15
gmannfungi: clarkb I wanted to help on fixing zuul config error more myself but could not get time. I will try if any projects does not respond or fix16:15
gmannplease send it on ML and we will track those here too16:16
clarkbI did a while back16:17
clarkbmy main concern with those errors is that many are due to project renames that were requested of the infra team16:17
clarkbit seems like if we don't do everything to complete a rename then it doesn't happen16:17
gmanni see16:17
gmannthose can be fixed easily 16:18
clarkbI think that if openstack is doing project renames which require a fair bit of effort on the infra side (though less now as we can better test and automate things) the least we should expect fo the projects is that they update their zuul configs16:18
fungipart of the problem there in the past stemmed from renames which occurred due to lack of project maintenance/interest, which also implied lack of interest in fixing the configuration errors that resulted form the renames16:19
gmannyeah, that should be part of project rename initiated by openstack contributor but it seem not everything is greped/searched and fixed  16:20
fungialso in a lot of cases it's broken rename-related configs in other projects which got fixed on recent branches/master but older stable branches were ignored16:21
fungi(project a declares required-projects including b, b is renamed to c, a fixes required projects list in master but doesn't care about their stable branches so config error persists on stable)16:21
gmannyeah, It think not having good search tool for stable branch leads them to be not fixed. as codesearch on master only16:21
fungihowever, zuul does report which branches are broken, so at least they can be cleaned up afterward16:22
clarkbfungi: exactly. It isn't ideal that hound can't index the stable branches but we give users more than enough tools to do this16:22
clarkbspecifically zuul calls it out after the fact, you just have to go and fix it at that point16:23
gmannkeeping 11 stable branch is another issue we end up ignoring such fixes in stable. I keep arguing to shrink this otherwise we will go with 20 stable branch at one time :)16:24
clarkbyes, it definitely adds more burden over time.16:24
gmannmaintainer has decreased but stable branch number to maintain increased/increasing in every release16:25
fungiand at some point it prevents us from discontinuing support for old platforms in opendev too16:31
fungiand makes it hard to remove tooling we deprecated years ago16:31
clarkbrelated, I was going to check on whether or not centos7 is still used16:32
gmanntc-members: is coming Tuesday 24 May 15:00 UTC works for the 'release name' discussion ?16:32
clarkbI thought I saw tripleo saying they were off of it, but wasn't completelysure of that16:32
dansmithgmann: yes16:33
gmannelodilles: ttx ^^ meeting time. 16:34
gmannaprice you too as there is some confusion on 'how Foundation will choose name/follow TC defined criteria or its own' that also we will discuss. you do not need to be in full meeitng but I can schedule that in the start of meeting16:34
fungidiablo_rojo seems to be not in irc at the moment, but she usually has a conference call at that time16:34
fungisince that's when we normally hold our weekly foundation staff meeting16:35
gmannI see, how about Tuesday 24 May 16:00 UTC ?16:36
gmanntc-members ttx elodilles aprice ^^16:36
dansmithgmann: yes16:37
gmannrosmaita arne_wiebalck slaweq spotz knikolla jungleboyj ^^16:39
slaweqgmann Tuesday 1600 UTC works for me16:43
spotzI can do the start but then will need to leave before the end16:44
ttxworks for me16:48
clarkbgmann: fyi http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html17:20
*** timburke__ is now known as timburke17:28
apriceyes, i can make that work 17:28
elodillesgmann: well, Nova meeting is at the same time, but if ttx will be there then I think rel-mgmt team is represented o:)17:59
elodillesttx: ^^^ is it OK for you? :)18:00
gmannelodilles: yeah, I am also planning to skip nova meeting that week. will add things in nova meeting wiki if anything.18:00
rosmaitagmann: tues 24 may 16:00 utc works for me18:38
gmannok, let me schedule and will update the link to join.18:40
jungleboyjgmann:  I can make that work.18:43
gmanncool18:43
gmannjungleboyj: rosmaita need more vote/review in this https://review.opendev.org/c/openstack/governance/+/84035418:44
rosmaitaack18:44
gmannthanks18:44
jungleboyjLooking.18:45
dansmithgmann: will you send an invite?19:03
gmanndansmith: i can, is google meet ok if so my account is hard stop on 1 hr. which is good :) but in case we extend we can use pro account too19:04
dansmithgmann: send me a list of addresses and I'll schedule with my pro account19:04
gmanndansmith: you can send it to all TC members and to community I will send the link on ML19:06
gmannhoping these email are upto date https://governance.openstack.org/tc/#current-members19:06
dansmithgmann: sent, check the time19:10
gmanndansmith: thanks, its all correct. 19:11
knikollai won't be able to make it at that time19:29
*** dasm is now known as dasm|off21:26

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!