Tuesday, 2022-03-22

*** clarkb is now known as Guest279003:17
*** ChanServ changes topic to "Incident management and meetings for the OpenDev sysadmins; normal discussions are in #opendev"11:52
*** Guest2790 is now known as clarkb15:01
clarkbHello, our weekly meeting is about to begin18:59
fungiohai19:00
ianwo/19:00
jentoiohi19:01
clarkb#startmeeting infra19:01
opendevmeetMeeting started Tue Mar 22 19:01:12 2022 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
clarkbI'm on my laptop today and realized I dont have my typical notes an dthe desktop is off so I couldnt' copy them off. Will do my best :)19:01
clarkb#link http://lists.opendev.org/pipermail/service-discuss/2022-March/000326.html Our Agenda19:01
clarkbWe do have an agenda though and we'll be following that19:02
clarkb#topic Announcements19:02
clarkbThe openstack yoga release is about a week away. As usual exercise judgement/caution when making changes to avoid impacting that process. That said we updated gerrit to get some bugfixes as well as gitea so it doesn't mean no changes19:02
fungiand kernel security fix reboots19:03
fricklerand zuul 5.1.019:03
clarkbyup. Basically use your judgement and exercise caution.19:03
fungito be fair, we've been constantly updating zuul anyway19:03
fungiwe upgraded from almost-5.1.0 to the commit which got tagged as 5.1.019:04
clarkbAlso the next ~2-3 weeks are super busy for me. I've got family in town, kids are on spring break, openstack release, PTG, I actually have to go to the dmv etc19:04
clarkbPleaes do ping me if something urgent or important comes up and I'll do my best to help, but my hours and availbaility will be weird for the next bit19:05
fungigood luck!19:05
clarkbthanks19:06
clarkb#topic Actions from last meeting19:06
clarkb#link https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-15-19.01.txt Last weeks minutes19:06
clarkbThere were no recorded actions19:06
fungii don't think we really do actions any more19:06
fungiwe could just drop this section19:06
clarkbwe do occasionally and they are worth calling out when they happen but ya if we don't have them then maybe just skip ahead19:07
clarkb#topic Topics19:07
clarkbwhich I'll do now :)19:07
fungihah19:07
clarkb#topic Improving CD throughput19:07
clarkbI don't know there has been much movement on this19:08
ianwnope, still on the todo list!19:08
clarkbI was thinking if we did want to make use of some ptg time this topic might be worthwhile, but we can discuss with an adhoc meeting or in review easily enough too19:08
clarkb#topic Container Maintenance19:09
clarkbI hvaen't seen any movement on this since the insecure ci registry got updated.19:09
clarkbjentoio: are you still interested in doing more of these? if so is there anything I can do to help?19:09
jentoioI recently started a new role so have been distracted. I should have some time to look at this week19:09
clarkbcongrats!19:10
jentoioI guess mariadb are next?19:10
jentoiothanks19:10
fungiand thanks for helping!19:10
clarkbjentoio: no there are a few more services that should get dedicated users first19:10
jentoioas long the etherpad indicates what to work on, I can start on it this week19:10
clarkbmariadb is less important because it has a semi dedicated user its just less ideal.19:10
clarkbjentoio: noted. I'll try to update the etherpad with some order of operations thoughts19:11
clarkband yes thank you for the help19:11
jentoioglad to help19:11
clarkb#topic Cleaning up old reviews19:11
clarkbWe managed to retire a bunch of repos and abandon their open changes. Since then I've started looking at the list of changes in system-config19:12
clarkbI've tried to do two things there. First is abandon any change sthat clearly no longer apply. The other is to rebase/refactor/update changes which are still likely helpful but have grown stale19:12
clarkb#link https://review.opendev.org/q/project:opendev/system-config+status:abandoned19:12
clarkbthat gives you an idea for how many changes we've abandoned. I think it is almost half the total open changes in system-config which is great19:13
clarkb#link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~19:13
clarkb#undo19:13
opendevmeetRemoving item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup2~19:13
clarkb#link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup219:13
clarkb#undo19:13
opendevmeetRemoving item from minutes: #link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup219:13
clarkb#link https://review.opendev.org/q/project:opendev/system-config+status:open+topic:system-config-cleanup19:13
clarkbI can't type19:13
clarkbThis is the list of changes that I'm trying to revive. They all use the topic:system-config-cleanup topic. If you have time to review thoes that would be great19:14
clarkbAdditionally if you look over your own changes and find some that can be abandoned that is helpful and if you have old changes that should be landed feel free to update them as necessary and set that topic on them19:14
clarkbNot much else on this topic. Its a slow process but we're slowly refining the set of outstanding work to things that actually matter which is nice19:16
clarkb#topic Retiring the old Gerrit repo19:16
clarkbOnce upon a time not that long ago we carried a fork of gerrit19:16
clarkbSince the move to Gerrit 3.2 and container builds we've managed to switch to upstream builds of Gerrit. We can use local patches in the build process similar to how distro packaging works to patch stuff if necessary19:17
clarkbwhat this means is we don't need the Gerrit repo anymor eand it can be retired. However, there is some question about what the best way to do that is due to the many branches in the Gerrit repo19:17
clarkbianw: ^ want to explain the options we've got?19:17
ianwthe overall important thing is, unlike other repos, we want this one to fall out of search engines19:18
ianwso usually we just leave old branches alone, but here we don't want them coming up before actual gerrit changes when you search for gerrit things19:19
fungiwhere you := anyone on the internet19:19
ianwso we can delete all the branches19:19
ianwor we can merge a "this repo is retired" commit that deletes everything to all the branches ... but this leaves the change history there to find19:20
ianwor we can leave it, and put some robots.txt in opendev.org to specifically disallow indexing on /opendev/gerrit19:21
clarkbI think google has been good about finding those updates and not listing the source code. I am wondering if we should do the normal process and then wait a bit for google to reindex (or figure out how to ask them to reindex quicker) and then we can delete after if still an issue19:21
clarkbI'm leaning towards not blocking with robots.txt since it would be a unique situation which we've found are good to avoid19:21
ianwthe normal process would be to leave the old branches, but i assume you mean to delete the content on all branches?19:21
clarkbya sorry on master and all the stbale-* branches19:22
fungii'm also fine with deleting all the branches... our "history" still remains in the form of gerrit change refs which will keep the relevant commits from being garbage-collected19:22
fungi(deleting the branch heads themselves, not simply replacing their content)19:22
clarkbya I'm not against that it just seems lke this is a useful experiment to see if that is necessary19:23
clarkbI think we're assuming it is, but knowing with more data would be helpful19:23
fungiprogressive changes are mildly inconvenient because setting the acl to read-only state will have to be undone manually to do anything else through gerrit19:24
fungibut it's certainly doable19:24
clarkbI think deleting branches is a little bit of an exception to that as you need super privs to do that anyway19:25
clarkbbut yes in general that is true19:25
ianwtbh i'm sort of tending towards deleting branches too, just so we don't have to revisit19:25
fungiwell, actually branch deletion is no longer owner-restricted. it can be delegated, and now is for openstack and one other project i forget at the moment19:25
clarkbfungi: oh good point, but I don't think we do that for this repo currently19:26
fungiwe don't, but we could19:26
clarkbya if others feel strongly about just deleting the branches I'm not opposed19:26
ianwi could put in the readme a URL to opendev.org that shows the changes in each branch19:26
clarkbthe content will remain in gerrit, and its usefulness to us is limited now that we are so far ahead and on the upstream code base19:26
ianwto review.opendev.org19:27
fungithe content will remain in gitea too, it's replicated there, you just can't access it through gitea without requesting specific commits or cloning and checking the named change refs out locally19:27
ianwand would i delete and replace the master branch with just a readme?19:28
ianwwe never committed anything to that branch, i don't think?19:28
clarkbya I think retiring the master branch as usual would still be good. No we didn't but it is still HEAD iirc19:28
clarkbthe way the repo is setup is there is a master branch which is likely very stable. A bunch of upstream/foo branches which were not modified compared to upstream. And then openstack/foo which we did modify19:29
clarkbdeleting master and upstream/* should be lossless due ot upstream having the branches. Then openstack/* will still hae changes recorded in gerrit19:29
clarkbI guess if others prefer deleting branches we can proceed with that19:30
fungimy preference is for whatever's simple and handled in a way that other projects could theoretically do without being gerrit admins19:31
fungiso i'm not keen on robots.txt or .htaccess changes on the server to block repo-specific requests19:32
fungigerrit admins or server sysadmins i should say19:32
ianwheh, there's a remotes/origin/upstream/test-to-delete so something wants to be deleted19:32
ianwso i will delete the origin/* and gerrit/* branches, and point HEAD to a branch with just a README on it?19:34
clarkbianw: I wouldn't update HEAD (there are problems with changing that value) just set the content of whatever HEAD is to a README in it (likely master)19:35
ianwok, so that's a hybrid approach where we assume the changes in master will fall out of search indexes after we merge a change to delete everything there, right?19:35
clarkbyes, I guess the othe ropiton is replacing all of master's history?19:36
ianwit seems like there's gerrit on the master branch, but it stops at "Date:   Tue Jun 7 13:41:36 2011 -0700"19:37
clarkbI guess the balance here is having enough content to indicate why it exist at all19:37
clarkbianw: ya it was fro mthe original import and then not kept up to date as future owrk happened on brnaches19:37
ianwI would put in the readme left behind there links to review.opendev.org and each branch, that shows the changes we committed19:38
fungithat's a fun memory, we were carrying a gerrit fork almost 11 years ago19:38
ianwso in terms of archaeology, if anyone ever cares, they could pull upstream gerrit, and then those changes that were on the branch, and have something like what was running19:38
clarkbyup19:39
clarkbit might be worth asking mordred if he has any concerns with that as he set up the forking system iirc19:39
clarkbI really doubt it though19:39
clarkband we're well enough past running the fork that it shouldn't matter for ou rday to day19:39
fungihe'll probably volunteer to light the match19:39
ianwso ... the conclusion is to delete all the branches, but leave a readme with sufficient detail to understand what used to be going on in the repo and how we used to run gerrit?19:40
clarkb++ I think that works for me19:40
ianwok, per the previous conversation you can give me an action item to do that if you like :)19:41
fungisounds good, thanks19:41
clarkb#action ianw delete old gerrit fork branches and leave breadcrumb readme on the existing HEAD branch as preparation to retire and set the repo as read only on review.o.o19:42
fungiwe're actiony once more! ;)19:43
clarkb#topic Scheduling Project Renames19:43
clarkbWe have a project rename request. As mentioned earlier my next few weeks are a bit crazy for me to be thinking about renames. I'm personally inclined to punt this until after the ptg as a result. But if others think we can/should do this sooner feel free to work towards that19:44
clarkbI think this is the 11-15th timeframe before things quiet down for me19:44
clarkb* of April19:45
clarkbMaybe pencil in the 15th and if we get organized sooner then graeat otherwise this is the plan?19:46
clarkbthats good friday though19:46
clarkbthat probably means less load (a good thing) but fewer people around possibly to help (less of a good thing?)19:47
clarkbI guess we can go with that as the rough schedule and tweak as necessary from here19:47
ianwi feel almost sure we have something booked over that weekend19:47
ianwshould we do similar to last time and put the gerrit upgrade to 3.5 in there too?19:47
clarkbI don't think we need to. Renames are pretty quick19:48
clarkband I worry if I'm driving it Ill have even less time to prep for that upgrade19:48
clarkb(things like the config update to force case sensitive username sare still in review though)19:48
mordred<fungi> "he'll probably volunteer to..." <- Burn it down!19:48
ianw:)19:49
fungii'll bring the petrol19:49
clarkbanyway I think we can plan for renames on the 15th for now. If we find we are behind we can push that back19:49
ianwclarkb: ok, i'll put on my todo list to go back and look at it all again.  i don't mind trying to drive the upgrade bits after i context switch in all the pre-work you've done19:49
clarkbianw: cool that would be helpful19:50
fungi15th is fine with me, thanks19:50
clarkb#topic Open Discussion19:50
clarkbianw: https://review.opendev.org/c/opendev/system-config/+/827774 i sthe case sensitivity change19:51
clarkbnot strictly necessary but a good belts and suspenders and reminder that we are relying on that behavior in production so should test thta way too19:51
fungii do have somewhere to be over that weekend, surprisingly (an interactive van gogh exhibit), assuming covid doesn't go crazy in the next few weeks19:51
fungibut friday i'm open19:51
clarkbit is difficult to test because they won't le tyou create colliding users anymore but that setting allows existing collisions to exist19:51
clarkbAnything else?19:52
ianwfungi: is that like https://www.visitvictoria.com/regions/melbourne/whats-on/art-and-exhibitions/exhibitions/van-gogh-at-the-lume-melbourne19:53
ianwclarkb: thanks, will look19:53
fungiianw: probably similar19:54
fungilooks like it19:54
ianwi thought it was very cool.  they must have had 100 projectors, i would have loved to have seen what sort of test-patterns they had to align everything19:55
fungiseemed like an opportunity to go out of town for an overnight trip and do something interesting without too much plague19:55
clarkblooks like fun19:55
clarkbAlso sound slike that may be it? I'll let everyone go then. Thanks!19:56
clarkb#endmeeting19:56
opendevmeetMeeting ended Tue Mar 22 19:56:25 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-22-19.01.html19:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-22-19.01.txt19:56
opendevmeetLog:            https://meetings.opendev.org/meetings/infra/2022/infra.2022-03-22-19.01.log.html19:56
fungithanks clarkb!19:57

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