[10:00:25] <dcausse>	 lunch
[12:41:33] <ebernhardson>	 \o
[13:05:45] <inflatador>	 <o/
[13:12:04] <ebernhardson>	 \o
[13:16:37] <dcausse>	 o/
[13:37:03] <inflatador>	 Any objections to me adding a couple of scripts to https://gitlab.wikimedia.org/repos/search-platform/cirrus-toolbox ? I'm thinking of ban/unban and recovery settings
[13:39:59] <dcausse>	 inflatador: sure, please go ahead
[13:47:23] <inflatador>	 dcausse ACK, thanks
[13:56:11] <dcausse>	 wondering what to do with pending changes on cindy, some should definitely be merged, MEDIAWIKI_IMAGE bump but the obsolete sury keys I'm not sure
[13:56:24] <ebernhardson>	 hmm, not sure
[13:56:50] <dcausse>	 having these pending is no big deal when they pile I'm always afraid of losing a couple
[13:56:59] <ebernhardson>	 dcausse: also, i'm not sure how i had passes before on the 5.x dps image, but i had to pull cindy back to the 3.x image (with updated command line) as it stopped finding the named containers
[13:57:11] <ebernhardson>	 the thing is...i'm also sure i saw it pass with 5.x a few times
[13:57:55] <inflatador>	 dcausse can't make pairing today, forgot that I have to take my son to dentist ;(
[13:58:00] <dcausse>	 you mean it passed with 3.x + increased heap?
[13:58:05] <dcausse>	 inflatador: np!
[13:58:15] <ebernhardson>	 for the obsolete sury keys, i guess the "right" answer is the images we use should be updated regularly?
[13:59:00] <dcausse>	 yes but seems like these dev images are not updated so regularly, I guess nobody complains because they rarely run apt there
[13:59:18] <dcausse>	 if only we had ghostcript installed in the image we would not need to pull anything new
[14:00:03] <dcausse>	 since it's a dev image I'm tempted to ask for ghostscript to be added?
[14:02:04] <ebernhardson>	 seems reasonable to me, could probably link PdfHandler as the place that requires it
[14:02:13] <ebernhardson>	 i think thats the one at least
[14:02:47] <ebernhardson>	 yea, $wgPdfProcessor defaults to /usr/bin/gs
[14:03:35] <ebernhardson>	 apparently there is a 13 year old task to move away from ghostscript :) https://phabricator.wikimedia.org/T38594
[14:03:42] <ebernhardson>	 from bugzilla
[14:04:32] <dcausse>	 :)
[14:07:22] <ebernhardson>	 disconnected from cindy tmux, was just checking what the diff was
[14:07:49] <dcausse>	 ebernhardson: so you mean dps 5.x does not work?
[14:08:14] <ebernhardson>	 dcausse: yea i had to change cindy back, although i didn't look too closely into why. It *should* work afaik
[14:08:27] <dcausse>	 just tested a fresh mw binary I compiled with this image it seemed to fetch the image properly
[14:08:51] <ebernhardson>	 a primary feature of dps is doing those container name lookups iiuc, it might have just been something i missed
[14:09:33] <dcausse>	 oh haven't checked that it's working tho, was about to mess up with cindy again
[14:10:22] <ebernhardson>	 should be reasonably easy to check via: ./mw docker mediawiki exec ping elasticsearch
[14:11:33] <dcausse>	 works with "ping opensearch"
[14:12:35] <ebernhardson>	 oh, i wonder if that was it and i was just being dense...i'll have to pull my local instance (for some silly reason i have one copy in ~/git/... that i dev from, and another copy elsewhere that runs my local mediawiki instance)
[14:12:55] <ebernhardson>	 i guess because i didn't want to break my mediawiki install while working on something
[14:13:57] * dcausse now wonders where we set CirrusSearchClusters for cindy
[14:14:40] <ebernhardson>	 dcausse: ~/.config/mwcli/mwdd/default/mediawiki/MwddSettings.php
[14:15:04] <dcausse>	 oh
[14:15:08] <ebernhardson>	 but at least historically we can't change that file directly, mwcli likes to overwrite all those files on startup
[14:16:59] <dcausse>	 ah yes, it's there "$wgCirrusSearchServers = [ 'opensearch' ]"
[14:18:06] <ebernhardson>	 can set the env var and see how it does, `DPS_IMAGE=... ./create-env.sh && ./run-integration.sh` should be sufficient
[14:18:24] <ebernhardson>	 shouldn't need to run the whole thing, i suppose if ./create-env.sh works thats probably enough 
[14:20:16] <dcausse>	 ok
[14:22:34] <dcausse>	 trying with cli compiled with https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/651
[14:39:55] <ebernhardson>	 school run, back in a bit
[14:47:27] <pfischer>	 I'll be a few minutes late for triage
[14:47:37] <pfischer>	 uh, Wednesday
[14:50:51] <inflatador>	 still at the dentist, won't be able to make Weds mtg
[15:34:03] <inflatador>	 Relforge doesn't seem to be able to form a net-new cluster. I think we might need to set `cluster.initial_cluster_manager_nodes` and/or `discovery.seed_hosts`
[17:32:17] <inflatador>	 ^^ looks like both settings are required
[17:36:54] <inflatador>	 now, how to set that without messing up other opensearch clusters that use the template
[19:42:10] <inflatador>	 I can add the new settings using environment variables and a systemd override, a la https://opensearch.isharkfly.com/install-and-configure/configuring-opensearch/index/#specifying-settings-as-environment-variables 
[19:42:45] <inflatador>	 It's disgusting, but that might let us add the settings on our clusters without affecting other opensearch clusters
[19:50:21] <ebernhardson>	 sounds plausible, but yea not the most amazing
[19:53:46] <inflatador>	 I think `discovery.seed_hosts` has replaced `discovery.zen.ping.unicast.hosts` since ES7, so we could probably fix that one everywhere
[19:54:48] <inflatador>	 Elastic basically hid all their old docs, trying to find this in the wayback machine with no luck so far
[19:59:31] <ebernhardson>	 :S
[20:03:41] <inflatador>	 I'm not sure that they should be advertising that their search results are powered by https://www.elastic.co/elasticsearch/elasticsearch-relevance-engine . It's not having the desired effect on me ;)
[20:07:16] <inflatador>	 https://www.elastic.co/guide/en/elasticsearch/reference/7.0/breaking-changes-7.0.html getting somewhere
[20:09:11] <ebernhardson>	 lol, i've had the same experience with their doc search, relevance is not great
[20:59:23] <inflatador>	 I one-offed relforge alpha, https://phabricator.wikimedia.org/T427306#11961305 definitely works. That could be a fallback plan if 0lly doesn't want to roll out the changes in opensearch.yml