[12:52:02] o/ [13:50:38] \o [14:30:14] .o/ [15:26:57] Trey314159: not 100% happy with it, but draft of glent/dym analysis: https://people.wikimedia.org/~ebernhardson/T262612-dym-ab-analysis-DRAFT.html [15:27:17] I will take a look! [17:28:12] ryankemper ebernhardson do y'all see any benefit to running OpenSearch benchmarks ( https://docs.opensearch.org/docs/latest/benchmark/ ) against EQIAD while it's still depooled? Context is mostly T396501 , but I was also thinking it could be useful if we start to seriously consider moving the secondary clusters to their own HW [17:28:12] T396501: Decide on/run a benchmark for DPE SRE-owned OpenSearch clusters - https://phabricator.wikimedia.org/T396501 [17:30:42] hmm, plausibly. Although poking at the pre-configured workloads nothing jumps out at me as highly relevant [17:31:31] Yeah, I was worried about that too [17:31:56] We did T117714 when setting up codfw initially [17:31:57] T117714: Load test the codfw elasticsearch cluster to verify it can handle production load in a switchover - https://phabricator.wikimedia.org/T117714 [17:32:11] I guess maybe it's better to wait 'till we have envoy, then we can switch over to test at any time [17:32:53] oh nice! /me reads [17:39:07] I think we just pool it, at first glance I don’t see a ton of value in the benchmarks [17:39:09] Dog walk [18:12:14] that's a great ticket, we'll definitely want to give that another look as we build out the new cluster [19:04:14] small patch for the staging updater's net policies, should unblock some relforge decoms: https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1155315 [19:24:35] picking up Simon from camp, back in ~1h [19:44:27] I'm curious about the WMF plan to migrate to OpenSearch from Elasticsearch. That migration seems well under way. The specific question I have is "How is the Elastica library being replaced?" or, "How will MediaWiki, through the CirrusSearch extension, speak to the backend search service? [19:44:47] From the Elastica project, they do not intend to support anything but Elasticsearch. From the OpenSearch project, they are not wire compatible with anything but Elasticsearch 7.10 - and the entire OpenSearch platform is a completely different product/project. [19:45:19] Maybe I misunderstand the role of Elastica in CirrusSearch, but the latest HEAD version of CirrusSearch requires Elastica >-6.0.1 AFAIK, the Elastica extension is the part that allows CirrusSearch to "speak" to the backend Elasticsearch. [19:46:09] rundg: for opensearch 1.x we can simply continue using upstream elastica, compatible with elastic 7.10. We expect for opensearch 2 it will need to be forked. [19:48:29] I see... I am watching as OpenSearch is releasing 3.0 now, so I want to understand the roadmap - including the various tools like Beats, Metricbeats, Logstash, Kibana and so-on for 3rd-party MediaWikis [19:49:28] at a bit of a general level, elastica is kind of a middle-ware, there is a lower level client that was available from elasticsearch, and is available from opensearch, in php. Our fork will hopefully only need to repoint at the opensearch variant. Plausibly we will trim the library down as well, since we don't need the whole thing [19:50:27] ebernhardson: thanks [19:51:03] at least at wmf logging/metrics is separate from search, although they happen to use the same server. I can understand wanting to consolidate that when running services though [19:51:15] s/same server/same software/ [19:52:09] i'm not sure on a timeline, we will migrate to 2.x but not in the next couple months. [19:53:15] Yeah, I've been maintaining a distribution / fork of the Meza project from NASA and I've added Kibana. I want to keep improving the infrastructure side but don't want to waste energy "bush whacking" off the beaten path. [20:36:39] ebernhardson: the PHP client may be useful https://docs.opensearch.org/docs/latest/clients/php/ [20:37:42] back