[07:45:51] ebernhardson / pfischer: T414095 seems to have been completed on your side, but is still opened. I'm assuming that it is fully completed (and had been for a while). Can you confirm that I can just close this? [07:45:52] T414095: Configure opensearch ML connectors/models - https://phabricator.wikimedia.org/T414095 [13:02:15] \o [13:34:30] huh, TitleSuggestIndexTooOld...something isn't rebuilding properly :( I wonder if that should just auto-file a ticket. [15:04:36] ebernhardson we're in stand-up if you're around [16:00:55] According to Nikerabbit, translatewiki.net only uses provided infra. It is hosted externally, according to their about page: https://translatewiki.net/wiki/Project:About/en. It is unclear who is maintaining it. [16:02:09] Can we apply our migration protocols to their indexes to check if any issues arise? [16:02:59] hmm, pondering [16:14:46] pfischer: It would probably be more tedious that way. The main thing our index checks do is see if the index has been re-created recently enough for a live rolling upgrade. In their case that would mean upgrading es7->os1->os2, because we can only go one major version at a time [16:15:14] i suspect they would want to simply recreate new indices on os2 and avoid the intermediate version. I don't know for sure but i suspect their data sizes are small enough that is practical [18:09:12] re: Translate wiki, if we do figure out a contact I'm happy to volunteer to help with the migration [22:10:46] I noticed that the "special" indices like audit log and `.plugins-ml-task` were blocking the semantic search CODFW cluster from self-healing. Looks like the max number of shard recoveries is 2 and those were stuck in INITIALIZING. [22:11:05] huh, that's awkward :S [22:11:48] yeah, I'll make a ticket but jotted some quick notes at https://wikitech.wikimedia.org/wiki/Data_Platform/Systems/OpenSearch-on-K8s/Misc#Opensearch_3.7_K8s%3A_special_indices_blocking_shard_recovery before I forgot