[10:38:13] dcausse: I pushed the (hopefully) final update to the ES client PR [10:38:41] pfischer: thanks! I'll take a look shortly (this afternoon or monday) [11:18:33] lunch [14:24:14] pfischer: migrating SUP to the new parent pom should be ready: https://gitlab.wikimedia.org/repos/search-platform/cirrus-streaming-updater/-/merge_requests/108 [14:40:21] Trey314159: I might need your help to rework the failing test in https://gerrit.wikimedia.org/r/c/search/glent/+/1011347 [14:41:20] I suspect that lower casing / UTF-8 support has changed from Java 8 to Java 11, but I think that you are better placed than me to at least define what the test should do. Happy to help with the implementation if needed! [14:41:30] gehel: I will take a look in a bit after I finish editing a documnt [14:41:35] *document [14:41:37] no emergency at all! [14:42:12] on that note, I'm actually going to start the weekend a bit early. On my way to https://www.technorama.ch/en/home with Oscar in a few... [15:00:10] \o [15:22:40] * ebernhardson looks at the data behind the young pool insuficient alert...maybe we need to have it wait for more bad data points. It did go under the limit, but it was an oddity of how we do the metric [15:24:02] basically, we take the max memory used by young pool over the last hour and make sure it's at least 500M. But when an instance shuts down the last datapoint or three might have reduced memory usage, particularly if it was banned ahead of time. So this fired an hour after the node left the cluster because in the last few minutes it's memory usage was low [15:24:36] in general i wonder if we should be using longer failure times, we generally have them at 1m and 5m, maybe 10m or 15m is more appropriate? [16:05:06] o/ [16:58:21] not entirely sure how to split where config goes...Should the rerender frequency (how often oldDocument is fired) be a cirrus config, or an api parameter in SUP config? [16:58:40] i made it an api parameter, but i dunno something seems awkward. probably fine [17:00:05] can the sup take this decision alone after getting the check results? [17:00:42] it probably could, but the awkwardness is that right now the fetch phase doesn't complete the target document, so i had the api return all concrete info necessary (index name, cluster group, etc) [17:01:28] i guess what i mean is that right now the api is providing enough info to make a complete UpdateEvent, but the SUP side doesn't have that. It could be added, but that currently lives in the producer and not the consumer [17:02:09] might just be moving the namespace map to common and reusing it on the sanity check outputs i guess? [17:02:31] well, we wouldn't know the namespace. I guess fetch would have to figure it out from the builddoc response [17:02:56] sorry I did not mean to change everything :) [17:04:24] even if this feels a bit awkyard seems like all the saneitizer config should now be owned by the SUP and thus be the oldDoc rerender freq could be passed to the saneitizer api [17:07:29] yea seems reasonable, i'll leave it as an api param wit hawkard documentation [17:10:36] dinner [19:22:59] * ebernhardson wonders if skipping `oldDocument` on pages with an edit in the last n weeks would make any difference to overall rerender rates