[08:59:17] gehel: I’ll be 2min late [10:03:12] lunch [13:01:48] reminder to put yoru thoughts in https://docs.google.com/forms/d/e/1FAIpQLSe9EWwmttd7dt0P7r3KzJs90VKkgIq0wF_yW7uAxIxbXEd03A/viewform?vc=0&c=0&w=1&flr=0 before the Wednesday meeting [13:12:05] gehel re: T280482 , do we need to validate opensearch as a replacement anymore? Was thinking we have already decided that but LMK if not [13:59:47] T280482: Validate that OpenSearch is a viable replacement for Elasticsearch for CirrusSearch - https://phabricator.wikimedia.org/T280482 [14:00:19] We haven't done much validation besides guessing that since it is a straight fork it should just work... [14:31:02] if we don't use opensearch, what's our alternative? I guess using the non-OSI Elasticsearch versions? [14:31:56] Migrating to a different engine. Vespa was mentioned, so was Lucene. It would be surprising that OpenSearch wouldn't work, but we have alternatives if needed. [14:35:38] We're going to have to port at least some of our ES plugins to opensearch for the mutualized OS cluster. I'm not sure that makes sense unless we're committed to migrating to OS completely [15:05:12] pfischer, ryankemper : Wednesday meeting, we're talking about future projects: https://meet.google.com/eki-rafx-cxi [16:05:00] workout, back in ~40 [16:39:48] ebernhardson: I wanted to check in on whether you'd had a chance to look at https://etherpad.wikimedia.org/p/recsys-search-tags-future and had any initial thoughts [16:51:26] back [18:04:54] isaacj: looked over it, all seems reasonable from the search engine side. There are some limits, but we aren't anywhere near them [18:08:21] lunch, back in ~40 [18:08:44] excellent thanks ebernhardson ! as I get started in Q1, I'll maybe set up a call with you all to better understand some of these limitations but that's good enough for now [18:09:06] from the search engine side, these are basically words. As long as the "language" isn't significantly larger than normal languages it should be mostly fine [18:11:44] cool, that's what I figured. I knew about the discussion around OpenSearch so mainly wanted to make sure that the weightedtags approach was something we could continue in the future [18:12:25] isaacj: yea the same concept still works there, we will have to port some plugins we made, but those have to be ported regardless [18:14:35] :thumbs up: [18:31:27] * ebernhardson corrected the dwell time numbers...perhaps just because we've been looking at the wrong numbers for many years, but now it's less believable :P at 5 minutes 28% are still on viewing the article (and this is using the visibleTimeout, so it pauses in background tabs) [18:32:22] or i'm reading the javascript wrong :P will re-review [18:46:02] back [18:53:40] ebernhardson is it going to mess anything up if we deliberately stop one or more of the SUP jobs to test the alerts we merged yesterday? Re: https://gerrit.wikimedia.org/r/c/operations/alerts/+/1009359 [18:55:22] inflatador: no it should be fine, it will pick back up when restarted [18:57:16] ebernhardson ACK, i'm going to stop flink-app-consumer-cloudelastic shortly and wait for alerts [18:57:22] ryankemper ^^ [19:09:10] OK, ran `helmfile -e eqiad --selector name=consumer-cloudelastic -i destroy`. Hopefully we'll see some alerts soon [19:14:07] inflatador: ack [19:14:53] looks like we're getting alerts in #operations but not #data-platform-alerts ...we'll wanna fix that too [19:19:23] inflatador: patch for T361268 when you get a chance https://gerrit.wikimedia.org/r/c/operations/puppet/+/1023937 [19:19:24] T361268: Service implementation for elastic110[3-7] - https://phabricator.wikimedia.org/T361268 [19:23:19] :eyes [19:24:35] inflatador: ah, knew I was forgetting something. gotta add conftool-data, one sec [19:25:00] ACK [19:26:41] inflatador: k, added [19:28:24] ryankemper ACK, I went ahead and +2'd /merged...will puppet-merge as well [19:28:56] ack [19:28:57] lunch [19:42:53] ryankemper I think we missed site.pp [19:42:57] 1 sec [19:43:18] inflatador: site.pp will be next patch [19:43:46] this is just to get the initial config in place [19:44:17] got it, hit me up when that patch is ready [19:57:24] I created the data platform alerts w/symlinks in the repo: https://gerrit.wikimedia.org/r/c/operations/alerts/+/1023942 . Is this OK, or should we copy the files instead? [19:58:42] looks like my symlinks are broken anyway ... hmm [20:00:20] OK, take 2 [20:10:00] looks like consumer-cloudelastic is alerting again...checking it out [20:13:29] yeah, the job seems to be restarting a lot...do we need to kick off a backfill or something? Re: https://logstash.wikimedia.org/goto/54f16bc3933666ac5400856cd1465d3e [20:21:32] hmm, did it perhaps have custom stuff deployed that wasn't in the repo? [20:21:41] * ebernhardson usually looks at diff before doing anything [20:25:36] deployed updated version, see if this works better [20:30:21] ooh, mail arrived. replacement laptop. But now i have to install linux and copy a bunch of stuff [20:34:25] ebernhardson ACK, thanks...it stabilized eventually. not sure if that was you or the passage of time [20:36:19] inflatador: i updated the container version, probably made a difference :) [20:39:02] ;) [21:46:29] hmm, getting ~100mbit transfering data wireless to my new laptop. Could be worse. Sadly my router only has two physical ports, and one has the cable modem plugged into it.. [21:51:53] I have soooo many wires. But I'm a little crazy about it. I used to run a cable headend ;) [22:15:50] oh, it's because the new laptop connected over 2.4 for some reason :S but i don't want to go mucking with it mid-transfer so i guess i wait