[07:42:18] o/ [10:10:04] lunch [11:03:12] lunch [12:45:22] o/ [13:03:46] o/ [13:31:21] \o [13:34:19] i'm thinking something along these lines for reworking parts of the reindxer ot better live in k8s world: https://phabricator.wikimedia.org/P80976 [13:36:43] nic [13:36:44] e [14:00:39] o/ [14:30:21] ebernhardson: I see "for alias in aliases:" in the stub, not clear what it means, because I understand that the state is on per index basis right? e.g. enwiki_content is SUBMITTED, frwiki_general is RUNNING [14:35:25] ah, def submitted() takes care of moving the state of all indices in a SUBMITTED state and I suppose will update self.state.indexes_in_state [14:36:34] perhaps it could get the SUBMITTED indices directly from self.state.indexes_in_state(AliasState.SUBMITTED) instead of having to pass aliases: List[IndexAlias] [14:38:08] the states sound good to me, I guess you could go INITIALIZED -> FAILED if you can't push the pod to k8s? [14:50:13] ebernhardson: I tried to release discolytics but that failed: https://gitlab.wikimedia.org/repos/search-platform/discolytics/-/jobs/581448 For some reason it debian package lists cannot be read from mirrors.wikimedia.org [14:51:30] dcausse: hmm, adding initialized->failed makes sense. Indeed i'm currently thinking of passing a list in, but it might make more sense to have functions that operate on a single instance [14:52:38] i guess i started thinking about initialized() which takes a list, since it has to decide which to start, but the others would quite sensibly work on a single index alias [14:53:45] i'm also wondering if we have to think about what happens if we cant talk to the k8s api for a few minutes...but undecided [15:52:59] tempted to switch search_after sort: _id with sort: page_id, page_id was added in 2022 https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/526621 hopefully it's everywhere now [15:53:52] dcausse: yea that should be ready [15:55:52] trying to figure out if there would be weird situation where search_after could miss a big chunk of docs (investigating T363521) [15:55:53] T363521: Completion suggester can promote a bad build - https://phabricator.wikimedia.org/T363521 [15:56:44] the doc suggests using a PIT endpoint to keep the index state while paginating but I can't find a good reason why that would be interesting for us [16:01:09] lunch, back in ~1h [16:08:11] dcausse: indeed i don't think we require a PIT pagination, if the doc has disapeared by the time we get to it then we don't need it anyways [16:57:03] * ebernhardson ponders if it should be initialized -> post_verify if we fail to submit, so that it goes through the same retry sequence as normal. But then post_verify needs to also understand maybe pod doesn't exist [16:57:30] i guess there could be a middle point? running -> (submitted, running) -> cleanup -> post_verify, and initialized -> post_verify for failure to submit [16:57:45] s/running ->// [16:58:31] but maybe just make post_verify skip cleanup if we didn't record a pod name [17:02:11] sure, that makes the pod_name optional in this state but should be obvious why it's not set? [17:04:58] yea i think that makes sense, no need to overcomplicate with additional steps [17:21:07] back [17:48:21] heading, have a nice week-end [17:48:28] \o [17:48:31] *heading out [17:48:33] o/ [17:50:34] .o/ [21:00:21] inflatador: 5’ late to pairing [21:02:16] ryankemper ACK, I'm around [21:28:49] ebernhardson we only use curator on apifeatureusage indices, right? Or are there other indices? [21:46:05] inflatador: pretty sure thats the only usage [21:53:33] ebernhardson cool, we're removing a bunch of stuff in https://gerrit.wikimedia.org/r/c/operations/puppet/+/1162035 and just wanted to make sure. We found T361647 as well..looks like we don't use it curator in cookbooks anymore either [21:53:34] T361647: Remove elasticsearch-curator dependency from Spicerack/Elastic cookbooks - https://phabricator.wikimedia.org/T361647