[09:06:39] hey [09:06:39] I don't have the energy to look at the code again, but there's an issue with the DWIM in hewiki. For the special namespace, we use the abbreviation "מי" (on an English keyboard, that's "nh"). It works well for identifying the namespace (it also recognizes that it's the Special namespace even when typed with Latin letters), but it doesn't [09:06:39] recognize the page name itself, and it has to be typed in Hebrew. [09:07:44] הנה ההמשך, באותו סגנון ובאותו ניסוח: [09:07:44] that is, "ue:cn", which redirects to the page "וק:במ" in the Wikipedia namespace, works perfectly, but something similar for the special namespace doesn't work. [09:10:10] (sorry for the Hebrew words; I copied a message someone else sent me on WhatsApp. I asked him to elaborate, and he had AI translate it 🤦) [09:10:55] I checked this myself, and it is indeed problematic, so I decided to write to you [09:11:12] ping dcausse [09:11:57] Neriah: thanks for the heads up, we'll take a look, would you mind filing a phab task with these details? [09:12:40] I will do it [09:12:51] ah I suspect it's because "Special:" completion searches is handled by mediawiki-core not CirrusSearch... [09:14:54] so possibly only the namespace part gets rewritten not the "title" part [09:16:14] I suspect it might need an extra hook to allow CirrusSearch to complement searches on special pages [09:27:46] T433224 [09:27:47] T433224: DWIM replacements don't work for a page in the Special namespace - https://phabricator.wikimedia.org/T433224 [09:28:34] Neriah: thanks! [09:30:11] Neriah: would you consider this regression compared to what was done before DWIM was enabled (does it break existing use-cases?) or just that searching for special pages should be consistent with the rest? [09:30:56] consistency [09:31:04] sounds good [09:31:13] thanks! [10:21:17] lunch [13:07:32] \o [13:28:30] does anyone remember how outbound Internet access for WDQS federated queries is setup? I always assumed it was envoy magic, but if anyone remembers LMK. Tickets T431976 and T433136 are sorta-relevant [13:28:30] T431976: wdqs v2: Setup internal routing for query federation between main and scholarly - https://phabricator.wikimedia.org/T431976 [13:28:31] T433136: wdqs-qlever: federation and eventgate posting don't work at all on k8s due to network policy - https://phabricator.wikimedia.org/T433136 [13:30:16] o/ [13:31:06] inflatador: blazegraph is told to hit the lvs endpoint [13:31:49] https://gerrit.wikimedia.org/g/operations/puppet/+/da5e447b81ef4bf9e89e884bb471914568426c59/hieradata/role/common/wdqs/main.yaml#96 [13:32:28] when the query wants to hit "https://query-scholarly.wikidata.org/sparql" there's some code in blazegraph that rewrite that to hit directly https://wdqs-scholarly.discovery.wmnet/sparql [13:33:45] dcausse ACK, what about for external endpoints? Typically outbound internet access is blocked, maybe that's not the case for WDQS hosts or maybe we use web proxy somewhere? [13:33:55] it bypasses the edge, the lack of CLIENT_IP header (only set on the edges) will also tell blazegraph to bypass rate-limiting [13:34:20] inflatador: for external enpoints it's going through the web-proxy [13:34:39] dcausse Nice, thank you for confirming [14:37:50] heads up that I just merged https://gerrit.wikimedia.org/r/c/operations/alerts/+/1312570 (Cirrussearch alerts) so if something suddenly goes off, you can blame me ;) [14:38:06] it's just changing alert verbiage so that's very unlikely [17:37:09] hmm, flink-app-consumer-cloudelastic-backfill-6bcf64c94b-nl85q has been running 5d10h :S [17:38:59] that does't sound good [17:40:03] trying to decide if it's stuck or what, not sure yet. [18:02:03] * ebernhardson isn't really sure :S [18:06:47] i mean it probably is stuck, i don't see it doing much, but unsure why [18:09:35] I'm not sure...we did the Trixie reboots last week, maybe that's part of it? [18:15:33] hmm, not sure. It seems to have last started a job on july 22, k8s shows the release is still out there and running, but the backfill release is supposed to shut itself down [18:16:00] Annoyingly `kubectl logs` only has logs from today, and logstash.wikimedia.org seems to not have the actual full logs [18:16:26] (kubectl logs shows logs today, logstash `App Logs (Kubernetes)` lists so logs since july 22 14:30:00 [18:16:34] s/so logs/no logs/ [18:16:53] (╯°□°）╯︵ ┻━┻ [18:46:20] killed and restarted the backfill, its now backfilling 1800 indices, so basically everything in cloudelastic. will see how it goes [18:46:40] (in theory eqiad and codfw are done reindexing, but i haven't double checked yet) [19:42:17] ACK, I guess we can watch flink do its thing from the deploy servers (notwithstanding the disappearing logs thing) [20:12:11] I'm migrating the icinga checks, so we still support `freeze everything` a la https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/spicerack/+/refs/heads/master/spicerack/elasticsearch_cluster.py#600 ? Just wondering if I need to migrate the check [20:12:22] inflatador: no, that doesn't exist anymore in cirrus [20:12:37] ebernhardson ACK, that's what I thought. Just making sure [20:13:05] * ebernhardson is giving a practice run of tomorrows regex talk to myself...and it's sounding frighteningly complex :P [20:13:14] * inflatador will make a separate ticket for removing from Spicerack [20:20:42] T433306 as promised [20:20:43] T433306: Remove no-longer-existing API call from Spicerack's `elasticsearch_cluster.py` and anywhere else we can - https://phabricator.wikimedia.org/T433306 [20:38:12] dunno how relevant it is, but this is the outline of what i intend to talk about tomorrow in the regex trigram accel deep dive: https://phabricator.wikimedia.org/P95290 [20:54:48] 👀 [21:49:00] It sounds interesting based on the outline. Looking forward to seeing `06-ngram-graph-full.dot` ;P