[06:51:09] <godog>	 inflatador: sweet! thank you for enabling 4lw in zk 
[10:37:24] <dcausse>	 lunch
[12:53:22] <inflatador>	 <o/
[13:33:32] <dcausse>	 o/
[13:51:08] <inflatador>	 dcausse pfischer I see we have a WMCS/Data Engineering sync that conflicts with our pairing, is it OK if we cancel?
[13:58:42] <dcausse>	 inflatador: sure
[14:00:00] <inflatador>	 dcausse cool, I cancelled our mtg
[14:18:25] <gehel>	 If someone with some familiarity with Maven could review : https://gitlab.wikimedia.org/repos/ci-tools/wmf-jvm-parent-pom/-/merge_requests/12 ...
[14:32:35] <dcausse>	 gehel: lgtm (can't approve nor merge on this repo)
[14:33:01] <gehel>	 I'll merge, your IRC approval is good enough for me
[15:02:36] <gehel>	 Wednesday meeting is starting in https://meet.google.com/eki-rafx-cxi (dcausse)
[15:57:25] <inflatador>	 workout, back in ~40
[16:50:51] <inflatador>	 back
[17:50:27] <inflatador>	 lunch, back in ~40
[18:21:51] <inflatador>	 back
[19:00:36] <inflatador>	 medical appointment, back in ~2h
[20:22:04] <inflatador>	 back
[20:31:50] <inflatador>	 I'll send out an email tomorrow, but FYI I'm working on a docs refresh in T356806 and will def need some help writing and reviewing
[20:31:51] <stashbot>	 T356806: Document review/refresh for https://wikitech.wikimedia.org/wiki/Search - https://phabricator.wikimedia.org/T356806
[20:39:45] <ebernhardson>	 sigh...i forgot that my reindexing script can't make api calls, because of private wikis :S
[20:39:57] * ebernhardson ponders a stupid hack that submits api requests via mwscript and FauxRequest :P
[21:35:55] <inflatador>	 Just restarted a single cloudelastic chi node and now cloudelastic chi is red...looking into it now 
[21:36:11] <ebernhardson>	 inflatador: oh, that would be because there was a reindex in progress
[21:36:31] <ebernhardson>	 inflatador: i suppose it should have deleted the bad index though, but it might depend how cirrus fails
[21:39:04] <inflatador>	 ebernhardson back to yellow, I assume you deleted the dangling alias?
[21:39:29] <ebernhardson>	 inflatador: no, i think what happens is you restarted the node, the reindex failed, cirrus cleaned up the failed index, then the orchestration has now started a new reindex
[21:40:05] <inflatador>	 ah, got it. thanks
[21:40:17] <ebernhardson>	 i'm curious if it will backfill appropriately, i suspect this is showing a problem in my orchestration :P
[21:40:41] <dr0ptp4kt>	 inflatador: look, they "heard" my pleas: https://9to5mac.com/2024/03/08/parallels-desktop-update-games-clipboard/
[21:40:42] <ebernhardson>	 it will register a backfill request for this time period, but i don't actually check for time overlaps when clearing out the requests after it completes (i didn't consider i could get 2 backfill requests) :P
[21:40:59] <ebernhardson>	 for same wiki at least
[21:41:35] * dr0ptp4kt oops didn't mean to distract with mention, got overly excited about clipboard
[21:41:46] <inflatador>	 dr0ptp4kt happens to the best of us ;)
[21:42:00] <inflatador>	 you can tell from the learning circle that I'm a clipboard enthusiast
[21:42:05] <ebernhardson>	 i think this is actually going to work, but only by accident because the backfill should finish before the backfill request is registered
[21:42:15] <ebernhardson>	 :)
[21:42:28] <inflatador>	 sometimes better to be lucky than good ;)
[23:08:48] <ebernhardson>	 briefly pondered if we could stop using 0 replicas during reindexing, i forget how much time it saved (was bundled with multiple fixes at same time). But unfortunately while it would stop going red, i think the reindex might still fail
[23:09:54] <ebernhardson>	 because the reindex tasks themselves aren't recoverable, and there is a reindex task per shard being reindexed spread around the cluster