Tuesday, 2023-07-25

clarkbhello, meeting time19:00
clarkbsounds like tonyb is unable to join today. I suspect it may be a small group19:01
clarkb#startmeeting infra19:01
opendevmeetMeeting started Tue Jul 25 19:01:35 2023 UTC and is due to finish in 60 minutes.  The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot.19:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:01
opendevmeetThe meeting name has been set to 'infra'19:01
clarkb#link https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/thread/LODRYKSZXR4VEE2OJF2HMJN5E5GXH3LF/ Our Agenda19:01
fricklero/19:02
clarkb#topic Announcements19:02
clarkbI'll not be able to make the August 8 meeting due to travel19:02
clarkbbut I intend on running next week's meeting.19:02
clarkbSeems like we also have service coordinator election type stuff coming up. I need to go look at timelines set in the last election19:03
fungii could chair on the 8th if others want a meeting19:03
clarkbthanks. We can sort that out when we get there I guess19:04
clarkbalso the bugs are really happy with my laptop screen  again19:05
clarkb#topic Bastion Host Updates19:05
clarkbNothing new here other than requesting reviews on the stack that implements shared encryption key backups19:05
clarkb#link https://review.opendev.org/q/topic:bridge-backups19:05
clarkb#topic Mailman 319:06
clarkbLooks like there are some recent developtments here. Fungi can you get us up to date?19:06
fungias discussed in last week's meeting, we're rolling forward with manual creation of a django site in its admin webui and association of the corresponding mailman mail domain. i stuck some notes in comments on #link https://review.opendev.org/86798119:07
fungii meant to stick them on a different child change. anyway i'll get that into a docs change19:07
fungii manually created a django site (per the notes there) for lists.zuul-ci.org and then set that as the site for the lists.zuul-ci.org mail domain19:08
fungii also manually applied #link https://review.opendev.org/867987 to production and restarted the containers just to make sure what we're seeing matches the earlier tests19:08
fungireally just the edit to /var/lib/mailman/web/settings.py19:09
clarkbfungi: will the other domains in mm3 get similar treatment once yo uare happy with the zuul results? Also, where does the dummy domain fit into the future planning here?19:09
fungii think we can dispense with the dummy domain i was originally planning to add19:09
fungithings seem so far to be working as intended with lists.opendev.org as our first site/domain19:10
fungibut keep an eye out for any subtle oddities in list post headers or post moderation19:10
fungior inconsistencies i haven't spotted in the web interfaces19:11
clarkbcool that helps simplify things19:11
fungiif all goes well, and once we get 867987 deployed officially, we can decide to either upgrade to latest mailman 3 with #link https://review.opendev.org/869210 or migrate more sites first19:11
clarkbfwiw the domain listing at https://lists.opendev.org seems to show what we want after your manual changes19:12
fungii'm in favor of upgrading first, before we migrate more sites19:12
clarkbmakes sense. I'll need to review that change I guess19:12
fungijust to reduce the blast radius if the upgrade goes sideways19:12
fungianyway, that's it for my update. nice to have a little progress on this again, hopefully it will pick up steam in the coming weeks19:13
clarkbto summarize then we need to land 867987 to sync up with your manual changes. Then we can upgrade mm3. Then we can schedule more list moves19:13
fungithat would be my recommendation, yes19:14
clarkbsounds good, thanks19:14
fungiand i saw your comments on 867987, will address those shortly19:15
clarkb#topic Gerrit Updates19:15
clarkbfungi updated All-Projects to reject implicit merges19:16
clarkbbe on the lookout for people finding the new behavior to be undesired. They should be able to override the setting in their own project acls but I think a global reject is safest19:16
fungiyeah, just a heads up to keep an eye out for any problems people may encounter, though i don't expect any19:16
clarkbThen seprately we have ~3 interrelated items that we should try and coordinate around19:16
clarkb1) Gerrit 3.7.4 update https://review.opendev.org/c/opendev/system-config/+/885317 2) jeepyb updates needing a new gerrit image deployment and 3) replication task leaks19:17
clarkbI think my preferred course of action would be to land 885317 and build new images if ew are happy with that change. Then schedule a restart to deploy 885317 which will also address 2). During that restart we should manually clera our the replication task files (or move them aside etc)19:18
clarkbif that sounds reasonable I should be able to help with that around 2100 UTC tomorrow or the next day etc so that we can do it during a quieter gerrit period19:19
fungii can do 21z tomorrow, sure19:19
clarkbthat assumes 885317 land sbefore then, but that seems reaosnably safe to assume19:20
clarkbI'll check in tomorrow morning then ad we can take it from there. fungi maybe you can take a look at the gerrit replication stuff before then too just to hvae a bit of familiarity with it?19:21
fungisure. where are the notes on that again?19:21
funginever mind, i see the links in the agenda19:21
clarkbprobably mostly in the changes i wrote around it and the upstream issues19:21
clarkb/home/gerrit2/review_site/data/replication/ref-updates/ is the host side path for the contents on review02 19:22
fungiyep, will refresh my noodle on those19:22
clarkbthey are in a different path on the container side19:22
clarkbthanks19:22
clarkbThat was all I had for Gerrit.19:22
clarkb#topic Server Upgrades19:22
clarkbI continue to have no progress here myself. I saw that corvus deleted the old zuul executors though so that is good cleanup19:23
corvusyup, all gone, and zuul still thinks it has 12 executors so i think i got the right ones :)19:23
clarkbexcellent19:23
corvusthat's zm, and ze upgraded to jammy now19:24
corvusalso the registry is jammy19:24
clarkbonly the schedulers remain in zuul land19:24
fungiand the lb19:24
corvusyep19:24
clarkbAnything else on the subject of server upgrades?19:25
clarkb#topic Fedora Cleanup19:26
clarkbSometime in the last couple days (the dateline makes it confusing) tonyb and I discussed making progresson this19:27
clarkbBasically plan is to copy roles as necessary, make modifications, point base-test at modified roles and test from there19:27
clarkbspecifically for mirror selection updates to fedora19:27
clarkbso that we can stop mirroring fedora before cleaning up the images entirely19:27
clarkbI don't know how far tonyb got on that. I know tony wanted to test things a bit locally before pushing stuff up (since our mirrors are public anyway this is something that can be done)19:28
clarkbHopefully we'll have changes we can review soon19:29
clarkb#topic Storyboard19:29
clarkbAnything new to report here? Should we drop it out of the meeting agenda until we've had time to process any next steps?19:29
frickleryes, I was thinking the same19:30
fungiwfm unless something changes19:30
clarkbThe needed gerrit restart is related to updating issues correctly but only the lp side I think19:30
fungiright, the sb equivalent has remained working19:30
clarkback19:30
clarkbLet's move on then19:30
fungibecause it uses the its plugin instead of hook scripts in jeepyb19:30
clarkb#topic Gitea 1.20 upgrade19:31
clarkbGitea has released a 1.20.1 version now (they appear to have backpedalled on allowing all url types in markdown by default for securiry reasons)19:32
clarkbI'm still trying to work through the breaking change slist and a list of unallowed url type swas on the todo. Hopefully 1.20.1 makes that simpler19:32
clarkb#link https://review.opendev.org/c/opendev/system-config/+/886993 Gitea 1.20 change.19:32
clarkbUnfortunately I'm struggling to collect hte access log files which is why that change currently fails in ci. I think I need to hold the node and check directly19:33
clarkb(Access log format changes in 1.20 and I want to confirm we still get something useful from it)19:33
clarkbThe other itme on the todo list that will need help is the theme color selection change. I'm not quite parsing the intended update given by the release notes19:33
clarkbw eneed to set some sort of attributes in the base template or something19:34
clarkbNo progress on the oauth2 jwt stuff unfortunately19:34
clarkbat least not according to release notes. I guess I can test that when I hold a node19:34
clarkb#topic Etherpad 1.9.119:35
clarkb#link https://review.opendev.org/c/opendev/system-config/+/887006 Etherpad 1.9.119:35
clarkbThere is a held node if you look at the child chnage of ^ and pull up the logs for the failed test run (sorry I odn't have that in front of my right now)19:35
clarkbAfter making the config change from false to null values for color and use rname the UI appears to act like it did in 1.8.x19:35
clarkbI did some simple testing with the held node and I think that 1.9.1 chnage is ready for review/testing by others and hopefully merging19:36
clarkb#topic Python Container Image Updates19:37
clarkb#link https://review.opendev.org/q/topic:bookworm-python19:37
clarkb#link https://review.opendev.org/q/topic:force-base-image-build19:37
clarkbI think this is moving along well. Mostly needs reviews at this point19:37
clarkbNote the limnoria image update should be approved during a period where we don't have any meetings running as the image update will restart the bot and interrupt any meetings19:38
fungiyeah, i keep forgetting to do that at an appropriate time, i only ever remember about it at inconvenient times19:38
clarkbheh ya I theoretically have time here but so many distractions19:39
clarkbI've also made a note in the agenda that we should consider deleting our old bare python version tags so that image build sfor anything still using them fail forcing a move to the distro + python version tags19:40
clarkband a zuul-jobs tool that can scan docker hub and gerrit to determine if change tags are leaked and can be cleaned up19:40
clarkbI can probably look at that second thing as it is probably similarish to the script we used to sync from docker hub to quay and back again19:41
clarkb#topic Meetpad LE Cert Refresh19:41
clarkbAs fungi pointed out we have a cert but the hanlder that syncs from the acme path on disk to the jitsi meet service path on disk didn't run so we don't have a new cert where we need it19:42
clarkbthis means simply restarting services won't fix this19:42
clarkbinstead we should determine what is necessary to rerun the acme system in its entirty so that it either succeeds and we win or it fails and we can debug further19:42
fungifrickler was the one who spotted that actually19:42
clarkbalternatively w ecan manually copy the file and manually restart services19:43
fricklerI'm not sure if the rerun will work if LE thinks the cert has already been refreshed19:43
clarkbianw: if you get a chance to see this, what do you think is the preferred way to trigger a cert refresh from scratch19:43
fricklerso the second option would be my preferred choice19:44
clarkbfrickler: ya there are some things we need to do to force the system to rerun again19:44
clarkbif ianw remembers those without us needing to dig into the acme stuff we should probably document it and attempt that with meetpad19:44
fungiin theory, the staged cert being absent would look like a newly-deployed server to acme.sh, right? which should force it to request a new cert?19:44
clarkbI think there is some record file it keeps that we can either edit a timestamp in or delete the file then it retriggers19:44
fungiahh, so there's more retained state than just the cert19:45
clarkbfungi: maybe? I think it keeps some state info in a config/metadata file though19:45
clarkbit may check both things19:45
clarkbside note we should followup with acme.sh on fixing that bug thta preventing us from upgrading to latest resulting in backporting patches instead19:45
clarkbI'll try to take a look at that stuff and if I hit a wall we can do the manual sync and restart for now19:47
clarkb#topic Open Discussion19:47
clarkbAnything else?19:47
fungioh, one change19:49
fungi#link https://review.opendev.org/888901 Add 32GB nodes Ubuntu Focal and Jammy nodes19:49
fungithat basically just duplicates the existing bionic nodes in vexxhost ca-ymq-119:49
fungiso probably uncontroversial, but i figure it might need another set of eyes/opinions19:49
clarkbya I think we can go ahead and approve that. I'll do that as soon as I'm done with the meeting19:50
fungicool19:51
clarkbsounds like that may be everything then. Thank you everyone!19:51
clarkb#endmeeting19:51
opendevmeetMeeting ended Tue Jul 25 19:51:56 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:51
opendevmeetMinutes:        https://meetings.opendev.org/meetings/infra/2023/infra.2023-07-25-19.01.html19:51
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/infra/2023/infra.2023-07-25-19.01.txt19:51
opendevmeetLog:            https://meetings.opendev.org/meetings/infra/2023/infra.2023-07-25-19.01.log.html19:51
fungithanks clarkb!19:52

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