[08:38:59] how do people manage checking out multiple gerrit reviews? I created https://phabricator.wikimedia.org/P74148 [08:44:37] as in, chained one, or unrelated? [08:44:39] *ones [09:02:08] I tend to do reviews in the web UI ; if I have multiple unrelated things I'm working on at once, they all live in different branches. If it's one change that's going to be several chained CRs, then they're just commits on one branch [09:06:52] possibly I have misunderstood the question though :) [09:12:06] Emperor: nah, you pretty much answered :) I find switching branches cumbersome as I cannot compare the contents of source across different branches or run tests/linters on one branch while I'm editing files in another so I'm trying to use git worktrees [09:16:22] diff across branches is "just" git diff brancha branchb [path{s} of interest] ? [09:16:59] I agree that one can't be doing things on two versions at once, but I think I'd find that too confusing in any case :) [10:17:22] Amir1: I did (technically still doing) https://wikitech.wikimedia.org/wiki/Incidents/2025-02-28_www.wikipedia.org_redirect could you take care of https://wikitech.wikimedia.org/wiki/Incidents/2025-02-21_pc7_parsercache_db_unavailability (doesn't have to happen now, when mitigated) [10:17:54] thanks for the report! [10:18:17] sure, today is a bit of a mess but I will get to it on Monday [10:18:21] it is still WIP, but did you see my request (the other is blank) [10:19:02] I would normally do it myself, but I am searching for help so I don't do all myself [10:29:55] sorry to bother you, it doesn't need to be done on monday, I just wanted to handle to anyone else, take any time you need [11:15:14] I will deploy and marge https://gerrit.wikimedia.org/r/c/operations/puppet/+/1125114 on monday unless I get some blockers [11:50:22] TZAG folks, I'm looking for a review of https://gerrit.wikimedia.org/r/c/operations/puppet/+/1125410 please? the system that is currently testhost2001 is being repurposed as ms-be2089 (to finally equalize the size of the two ms clusters), so the install machinery needs to know what to do with the "new" host [13:29:38] I missed this, checking [13:32:35] TY [13:33:10] wait [13:33:30] ah nothing [13:33:52] the only thing I haven't checked is if it needs some particular hiera key [13:34:17] but I am guessing that wouldn't be a blocker for reimage [13:34:35] the other question would be if it is on the right network, but that won't be part of puppet [13:34:52] other than that, looks fine, double checked the regex [13:35:17] well, whatever bash does there, if it can be called a regex [13:42:38] :) [13:47:50] Pattern Matching per bash(1) [14:26:47] is gerrit unresponsive? [14:29:01] yep, seems very slow [14:29:15] see ops- [17:29:16] Emperor: _joe_: https://test.wikipedia.org/wiki/The_Userscript_Tou look at the image sizes vs. the url of the images [17:29:28] Amir1: moving the conversation here: regarding creating a dedicated repo for auto_schema on gitlab: [17:30:08] federico3: I created https://gitlab.wikimedia.org/repos/data_persistence/dbtools/auto_schema long time ago [17:30:09] I've noticed that there's many repos all under sre, I'd suggest creating a Data Persistence subgorup under https://gitlab.wikimedia.org/repos/sre [17:32:55] ok, then I'll move the commits into that one [17:43:46] Amir1: heh I need access rights please :D [17:45:01] federico3: I approved both [17:45:09] (to Owner) [17:46:26] Amir1: tadah https://gitlab.wikimedia.org/repos/data_persistence/dbtools/auto_schema/-/commits/main?ref_type=HEADS [17:46:53] \o/ [17:46:54] with some git-fu to keep the history [17:52:11] yeah, git filter