19:00:10 #startmeeting infra 19:00:10 Meeting started Tue Feb 27 19:00:10 2024 UTC and is due to finish in 60 minutes. The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:10 The meeting name has been set to 'infra' 19:00:16 #link https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/thread/6INGNPH2APYO7GUZ2HFJZPTLQTGITTS7/ Our Agenda 19:00:39 #topic Announcements 19:00:47 I had none that aren't otherwise covered in the normal agenda 19:01:05 May as well dive right in 19:01:07 #topic Service Coordinator Election Results 19:01:12 announcement: there are no announcements 19:01:20 I was the only nominee so I guess I am "it" by default again 19:01:29 \o/ 19:01:35 #link https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/thread/6C4TIQVP2R6AXLN3AKMSOR66DKURRSNC/ 19:01:36 clarkb: congrats! 19:01:43 to you and to us! :) 19:02:02 I don't have anyting to toast with at my desk but I wish I did :) 19:02:34 thank you for your (continued) service 19:02:58 #topic Server Upgrades 19:03:06 #link https://review.opendev.org/c/opendev/system-config/+/905510 Upgrading meetpad service to jammy 19:03:46 tonyb: not sure if you're awake but I remain happy to help with this if I can be of assistance. Maybe we should go ahead and approve some of these test specific changes? 19:04:32 Let us know if we can help. 19:04:37 Any other server upgrade business? 19:05:56 #topic MariaDB Upgrades 19:06:18 as mentioned previously we're going to try to rely on the MARIADB_AUTO_UPGRADE flag 19:06:25 Paste, Etherpad, Gitea, Gerrit, Refstack, and Mailman could use upgrades. Starting with Paste due to its simplicity. 19:06:30 #link https://review.opendev.org/c/opendev/system-config/+/909471 Upgrade paste.o.o mariadb to 10.11 19:06:44 at this point I've got reviews needed and sentiment seems to be just go for it 19:06:57 ++ 19:07:18 ++ 19:07:25 I'll try to do that tomorrow morning then as I should have few distractions at that point in time and can watch it 19:07:47 and if that goes well we can write changes for the other services and do them one by one 19:07:57 sounds good 19:08:15 #topic AFS Mirror cleanups 19:08:43 OpenSUSE Leap has been (mostly) removed. There are some mirroring script bits that are sticking around until centos 7 is removed 19:08:59 The removal of Debian Buster is in progress now. You can use topic:drop-buster to find changes related to that 19:09:14 we're currently stuck on the removal of wheel cache build jobs for buster on the openstack/requirements repo 19:09:42 tonyb: do you think you can quickly review those changes and then I can followup with similar changes to remove centos 7 and xenial? Or would you prefer I update the existing changes to remove all three from requirements at the same time? 19:10:26 if not, I can just approve as is tomorrow I guess 19:10:34 yup I can do that 19:10:46 I think the unmaintained/yoga branch might be weird too, but so far testing seems happy on all the branches just need reviews 19:10:48 tonyb: thanks! 19:11:09 once that is done we'll be able to drop the nodeset and then we can do nodepool and mirror cleanup last 19:11:27 the depends on metadata should capture all of that in the current changes 19:11:59 once buster is gone I'll keep chipping away at this with centos 7 changes then after that xenial 19:12:12 sounds good. 19:12:19 #topic OpenDev email hosting 19:12:34 Have we had any time to form opinions on this? 19:12:56 I think for myself if I were tasked with setting it up I'd look for hosted mail beacuse I've done that before but I've never self hosted 19:13:07 but I'm happy to learn if others are interested in self hosting 19:14:20 i'm on the fence as to whether we host it ourselves. i don't mind being a mailserver admin (on top of already doing it for lists01), but i also see the argument for not unnecessarily burdening ourselves with more work 19:15:12 * frickler is also undecided. less work vs. security vs. more control. not sure which way to prefer 19:15:37 yup thats where I'm at too 19:15:51 it's not urgent, we can mull it over for longer, i expect? 19:15:56 ok, I don't think we are in a hurry to solve this so we can continue to sleep on it 19:15:58 yup exactly 19:16:03 okay 19:16:23 I think if someone was ready to address this right now we'd make a quicker decision but I get the sense we all have plenty of other stuff going on already 19:17:07 I'll continue to take temperature on this unless I get told we should drop it from the regular meeting agenda 19:17:20 #topic Gitea 1.21.7 Upgrade 19:17:32 we are running 1.21.5 and there have been two bugfix releases in the last few days 19:17:37 #link https://review.opendev.org/c/opendev/system-config/+/909941 19:18:11 There were no template updates that I saw and I cross checked the JWT secret config modifications that were made and I'm 99% certain they were done in a backward compatbile way and we don't have to change anything on our end 19:18:23 all that to say I think we're ready once reviewers are happy. Maybe we can get that in today? 19:19:10 I can be around to monitor if people are happy with the change 19:19:27 #topic git-review vendoring the commit message hook 19:19:32 #link https://review.opendev.org/c/opendev/git-review/+/910275 19:19:46 This is an idea that has been kicked around for some time. fungi finally got around to implementing it 19:19:53 pretty straightforward, hopefully 19:19:55 I need to review the change myself. 19:19:58 not much to say about it 19:20:39 though in implementing it i did spot a design issue with file permissions on the hook script, which resulted in a separate change to address 19:20:41 sounds good to me; i was just wondering if there's any extra context i was missing (like some urgent new issue); but sounds like it's just "good idea; long time coming" 19:20:44 I think one important note is that while the hook script has had minor changes over time the format of the change id has not 19:20:53 so in theory a hook script from 2013 would work today and vice versa 19:21:22 corvus: ya I think there are a handful of good reasons to do it and the count got high enough to actually write the change 19:21:40 yeah, my only real concern is if gerrit makes a change in the future which requires updates to that hook 19:22:07 and for sites which could conceivably be depending on users getting a modified version of the hook specific to their needs 19:22:38 but the change does provide a non-default escape hatch for those situations 19:24:12 ++ I'll review later today 19:24:23 #topic Project Renames 19:24:26 * tonyb too 19:24:32 We have a request for a project rename 19:24:54 (un)fortunately we're quite near the end of openstack's release process and historically we've avoided doing renames during this time 19:25:00 #link https://releases.openstack.org/caracal/schedule.html 19:25:22 I think this is fine as it gives us time to collect any other renames that may need to happen and do them together as well as improve the rename process 19:25:37 in particular i think we should consider updating the playbook to move aside the gerrit replication waiting queue dir 19:25:55 what is the actual rename? 19:26:07 frickler: vexxhost/ansible-role-frrouting > openstack/ansible-role-frrouting 19:26:25 starlingx has brought up the idea of renaming some things as well but they haven't actually requested we do that 19:26:39 we can check with them to see if they are still interested and bundle everyting together 19:27:01 what downtime is there for renames? 19:27:03 so that would also require a matching governance change? means we couldn't/shouldn't do it right away even if we wanted to? 19:27:21 frickler: correct, though I think that also exists and mnaser is happy for it to move out of vexxhost/ 19:27:43 tonyb: renaming is actually an unsupported task in gerrit. To do the renames we shutdown gerrit, move things on disk, then start gerrit and reindex 19:28:10 tonyb: then we also have to rewrite things in zuul etc to match but that can be done in the runnign system typically 19:28:47 also gitea api calls and storyboard database edits if they use sb 19:28:49 okay. that's what I thought. so the impact is wide but short (hopefully) 19:28:59 clarkb: yeah, but similar to what we discussed in #opendev earlier, I'd like to see positive TC feedback before proceeding 19:29:09 frickler: sure 19:29:13 tonyb: yeah, we scripted the entire thing in ansible, so it's about as fast as a gerrit restart 19:29:20 looking at a calendar I think we can pencil in April 12 for a rename 19:29:25 minus the lingering impact of the online reindex for the affected repo(s) 19:29:34 okay. thanks 19:29:35 that gives us a target and a deadlien for getting paperwork in order 19:29:45 the zuul schema has changed since our last renames; possibly in a way that may necessitate an update to the scripts 19:30:00 corvus: thanks for calling that out, i had forgotten 19:30:11 tonyb: ^ also we rename project keys in zuul 19:30:16 corvus: good to know. We already do a rename of the project keys using the cli tools 19:30:27 corvus: are you concerned about the historical job data in the sql database? 19:30:32 we must do a db update right? 19:30:33 12.4. is the last day of the ptg, not sure I'd have energy left then 19:30:37 yeah that's what i'm thinking of 19:30:41 corvus: I don't think we currently do a db update 19:30:46 okay. 19:30:50 okay, so we just orphan it? that's fine 19:30:58 corvus: which is probably fine you search for vexxhost/foo instead of openstack/foo to see that data 19:31:08 I think we can live with that since it is historically accurate and reduces our overhead 19:31:09 yeah, wfm. i just couldn't remember. 19:31:39 frickler: oh good callout 19:32:00 April 19 then? Any conflicts there? 19:32:02 yes, let's not plan anything over top the ptg. i'll be busy enough ;) 19:32:35 2024-04-19 wfm 19:33:08 sounds good. 19:33:19 +1 19:33:27 ok I can pencil thati nto the wiki agenda and I'll ping ildikov to see if starlingx should look at hte opportunity too 19:33:41 #topic Open Discussion 19:34:21 I noticed this morning (after I sent the agenda last night) that I've been asked to schedule PTG time for opendev because I signed us up. I'm thinking that it may be best to wait until most other projects have scheduled their times so that we can slip a few hours in during times that are less problematic? 19:34:47 but also with the expectations that yall may be busy with other PTG stuff and I'll be doing more office hours like content on my own 19:35:28 obviously I can handle office hours in the apac timeblock 19:35:33 any concerns with that approach? Also happy for people to propose times that work well for them 19:37:07 Great I'll proceed with this plan of action then 19:37:16 having something in the APAC/EU block might be nice. because we could also use more people from that timezones 19:38:02 frickler: is that the 04-07 UTC or 13-16 UTC block? 19:38:11 the former 19:38:32 ack. I think I can make some of those hours work for me too. I just have to stay awake long enough 19:38:40 i could stay up late for something early in that timeframe 19:39:06 04-07 is basically 11pm-2am local for me 19:39:42 anything else? 19:40:19 I'm only one infra-root but I can for sure do that block 19:40:35 tonyb: ack 19:40:48 I'll give it a couple more minutes but I suspect we can end early 19:41:01 a reminder I'm happy to watch the gitea 1.21.7 upgrade today after lunch if others are willing t oreview it :) 19:42:02 I can do that. 19:42:34 sounds like that is everything. Thank you for your time today! See you here next week same time and location. 19:42:48 #endmeeting