[09:49:00] dcausse: o/ [09:49:06] elukey: o/ [09:50:30] I just moved kafka-main1001's broker to PKI, first step to finally solve https://phabricator.wikimedia.org/T291905 [09:50:51] just wanted to let you know since in the next months the task will have its second birthday :D [09:51:34] hope to roll it out in both main clusters during this week or the next [09:53:37] elukey: thanks for taking care of this! :) [09:55:44] tbh we paused a bit the work to switch to TLS for kafka connection but once this is done I guess it might make sense to be consistent and use tls everywhere [09:56:05] ah yes it would be really nice [09:56:17] another big and open question would be "shall we migrate to kafka 3?" [09:56:26] but it would require a cross-team effort [09:56:33] it is like the Kubernetes upgrade work [09:56:41] but we are lagging a lot behind mainstream [09:56:50] yes... kafka has become such a central piece of the infra... [09:57:51] and I suppose a rolling upgrade is not going to work here so we need to shutdown all clients [09:59:21] it will need to be tested, I really hoped it works otherwise we are in trouble :D [10:00:01] :) [10:01:29] but to your q, if you ask me, it's not great to be very far behing upstream and kafka is too important to be neglected [10:17:44] +100 [10:18:03] I opened a task a while ago, I'll try to reping peopel [10:18:05] *people [10:19:55] thanks! :) [10:19:58] lunch [12:28:07] elukey: we hope to test latest kafka and Kraft mode wwith Kafka stretch...if we ever find time to do it [13:05:19] the updater is running with the flink-op on the dse cluster, Completed checkpoint 10 for job 94ec61137dc8814f4558116848dd29cc! [13:05:43] still need to investigate the logs to understand the classloading issue [13:05:55] o/ [13:15:55] dcausse is that where we left it Thursday or have you made progress since then? [13:16:40] inflatador: this was building a new app with https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/904797 [13:17:37] if you note line 33, the "case None" is transformed into a "case _", it no longer wants to perfectly match the None object and I guess that made it work [13:18:39] I still need to understand why we had this problem before with "case None" but overall it means that we can more forward with testing how to operate the job with the flink-k8s operator [13:19:25] Cool [13:21:50] I have a hard stop today at the end of our mtg time, have to take my son to the doctor [13:23:43] hope it's nothing too serious, feel free to cancel our meeting [13:25:56] Probably the same illness me and his brother had already in the last 2 wks...we can do the mtg but I do need to stop on time [13:32:01] ottomata: ah wow ok! Lemme know if you need help! [13:40:05] elukey: we don't have any active time or plans to allocate to it right now, if you think you have spare cycles to get it set up...maybe come join event platform for a few sprints! :) [13:42:57] yeah I can imagine, the task is big for sure [13:43:14] we probably need to form a kafka interest group like the kubernetes one [14:30:43] Doctor appointment, back in ~1h [15:02:43] dcausse, mpham, ebernhardson, Trey314159: triage meeting https://meet.google.com/eki-rafx-cxi [16:16:49] back [17:23:12] dinner [17:25:36] lunch, back in ~1h [18:19:30] back [19:08:20] ryankemper, inflatador: as part of T331896, mutante is doing some changes to traffic config for query-preview.wikdiata.org. [19:08:21] T331896: upgrade miscweb VMs to bullseye - https://phabricator.wikimedia.org/T331896 [19:08:34] It might make more sense to coordinate with him to remove all this instead [19:08:40] I'll let you ping him! [19:09:13] ack! we’ll take a look during our pairing in a couple hrs [19:14:48] ryankemper: that might be a good occasion to let mutante do the cleanup (or at least part of it). Might be less work for him anyway. [19:18:34] I'm still looking at T333129, after mpham helped me understand what that actually was about (I read too fast the first time). [19:18:34] T333129: If " Category:+s " exists, make it appear first in search results - https://phabricator.wikimedia.org/T333129 [19:20:17] https://commons.wikimedia.org/w/index.php?search=Typewriters&title=Special:Search&profile=advanced&fulltext=1&ns14=1 has Category:Typewriters as the first result, but https://commons.wikimedia.org/w/index.php?search=Typewriter&title=Special:Search&profile=advanced&fulltext=1&ns14=1 does not even have it on the first page. That seems wrong. Could there be something about how we index categories titles? [19:20:47] Some stemming rules that we don't apply in that case? [19:25:24] Trey314159: ^ maybe you have a better understanding than me [19:25:45] looking [20:01:07] gehel: Stemming applies as you would expect it to—both typewriter and typewriters category searches get 384 results; **ranking** is the problem. We prefer exact matches, so, in the typewriter(s) case, there are lots of individual typewriter brands/models that are ranked higher than the plural category. Other categories have redirects from the singular to the plural, so Category:Dog is a soft redirect to Category:Dogs. (OTOH, [20:01:07] Category:Cat and Category:Cats are both disambiguation pages, but also have images on them anyway.) [20:01:13] The +s rule is also much too simple. It doesn't work for plenty of words—most words that end in s, z, sh, ch, or y, names, and *lots* of words not in English. It can also generate (not even plural) false positives like bas (as in the name, or bas-relief) → bass, or Fungu (an island) → fungus. Also, on Commons, we shouldn't just solve this problem for English. [20:01:15] We need either (i) some sort of lightweight alias system so "Category:Typewriters" can match Typewriter, machine à écrire, Schreibmaschine, etc. without a billion redirects, or (ii) some sort of boost on categories or may titles in general (Commons and elsewhere) when the entire query matches the entire category/title name. [20:02:04] *or maybe titles [20:04:18] Trey314159: thanks! makes more sense now! Any chance you could leave a comment on the ticket? [20:04:28] yep, already on it