[10:11:01] gerrit seems to be unavailable on my end [10:11:58] sorry false alarm [12:38:37] gehel inflatador Trey314159 please fill out the offsite spreadsheet today, thanks! https://docs.google.com/spreadsheets/d/1TH5onQXwhaBAN89-1lZWog32SvwCoqWfEWwLkhtBqNQ/edit#gid=1374215583 [13:18:59] cbogen_ so the library and tea tour are out? [13:20:44] ebernhardson: are you around [13:21:10] cbogen_ NM, I see that from your email [13:22:29] I have to check with my wife, pretty sure she bought tickets for some of those activities that sold out [13:30:15] Anyway, don't worry too much about it, I'm sure we'll figure out something [14:05:27] Nope! She didn't [14:06:21] updated [14:11:28] ejoseph: g'day [15:01:29] are we retroing today? [15:44:19] volans if you're around, I'm ready for the AAAA records in eqiad, list of hosts at https://phabricator.wikimedia.org/P28365#121968 [15:45:34] Trey314159: i may need your writing talents :P I've now tried and failed multiple times to write an i18n sentence that describes what asking for sectiontitle in an api request does for T306477. It says 'Adds a parsed snippet of the matching section title' and at this point, it would be easier for me to simplify the implementation than write this sentence :P [15:45:34] T306477: srprop "sectiontitle" has no effect in list=search API - https://phabricator.wikimedia.org/T306477 [15:47:02] inflatador: I'm a little bit busy right now, if I get myself free I'll ping you in a bit [15:47:23] volans ACK, no hurry [15:48:28] ebernhardson: LOL! that is a very engineering approach to the problem! I'll read over the ticket and see if I can help. [15:53:05] the difficulty i guess is that the implementation is dumb :P You can not ask for categories, ask for sectiontitle, and you don't get the sectiontitle returned because the categories matched [16:13:50] Going AFK for the next ~40m. Will not make the Puppet window, but if you need any merges hit up ryankemper or I'll be happy to help once I get back [16:52:54] back [16:53:43] inflatador: if you want I can now [16:54:19] volans ACK, ready when you are [16:56:37] inflatador: all ready, I'm just waiting that teh current run of the dns.netbox cookbook from Andrew completes to avoid spurious diff for him [16:57:04] ok, done, starting [16:57:29] changes in netbox done, running cookbook [17:01:23] inflatador: all done, updating task. The hosts are all yours [17:02:59] Excellent, thanks volans ! [17:04:10] looks like the records are propagated [17:24:27] ebernhardson (and maybe mpham): after looking at T306477 more closely, I think the code should be changed, honestly. The API shouldn't supress categories and section titles in the way the current UI wants to prioritize them. It should give you everything you ask for, and the Special:Search UI should sort out it's own situation itself. That said, in either case—leaving it as is or changing what the API delivers—the docs should [17:24:27] be updated because they are very opaque. I'm working on a draft... I'll have it to share in a little while. [17:24:28] T306477: srprop "sectiontitle" has no effect in list=search API - https://phabricator.wikimedia.org/T306477 [17:34:25] lunch, back in ~45 [18:09:04] ebernhardson: ask for some wordsmithing, get some wordsmithing, along with gratuitous feature requests and more! https://phabricator.wikimedia.org/T306477#7961335 [18:49:00] Ryan and I are starting the Cloudelastic bullseye upgrades, no service interruptions expected [19:15:31] meh, cindy ran out of disk space again. generated 3G's of error logs over ~12 hours. I guess we need to move the logs somewhere else after each run and only keep x number of directories or something [21:28:27] at least it was a real problem, a change in mediawiki core means everywhere we ran child maintenance scripts (everywhere) stopped passing arguments [21:35:12] mpham: thanks for the great updates in asana! really helps to get the whole birds eye view [21:35:15] and wrt to this question: [21:35:18] > thought to self: is our software just always perpetually out of date and needing to be updated? or are we over-emphasizing how often we need to update software? It seems like we are constantly chasing updates that come out faster than we can get on the latest version, which is not sustainable. Is this a sign that our architecture (or lack of it) is so poor that we're going to constantly be stuck playing whack a mole? [21:36:05] my thinking is that it's a sign how far behind we are on upgrades in general (understandable given our team splitting limited resources btw search & query service), as well as a sign of the need for better automation around elasticsearch version & os upgrades [21:36:38] the latter is improving with some of the work we've been doing on the elasticsearch `rolling-operation` cookbook to make both reimages (os upgrades) and elasticsearch version upgrades easier, so that side of things is improving [21:37:36] but ultimately since we were already on a pretty outdated OS version plus two (now one since we've done the `6.8.21` upgrade) elasticsearch versions behind, it makes sense that it feels like we're stuck in a loop there [21:39:52] i suppose i could also note that CirrusSearch is one of the last extensions to be ready for php 8, in part because of the elasticsearch 6 dependency for which there aren't any php 8 compatible client libraries [21:40:07] FYI, I'm about but Ryan is still working on cloudelastic1004 . The reimage keeps failing, so we're 1 host down in that env [21:40:10] thanks for the context! i wasn't sure if i came in at a weird time when lots of things were out of date/end of life. Or if it's a reality, trying to think about how we can either stay on top of things better, or better account for this work without feeling like we're on a treadmill [21:40:19] errr...I'm about to leave, that is [21:55:03] ebernhardson: so just to make sure I'm understanding, CirrusSearch being ready for php 8 is blocked on the ES 7 upgrade, thus why it's one of the last extensions to be ready? [21:55:15] (I should probably already know this, but alas) [22:06:29] ryankemper: yea, thats it. there's probably a ticket, sec [22:07:03] https://phabricator.wikimedia.org/T283275 [22:07:46] now, it's not like upgrading is the only possiblity. We could for example make our own copy of the client libraries and hack them until they are compatible with php 8. But that is firmly down the "never going to upgrade" road :) [22:08:02] never going to upgrade elastic, that is [22:54:28] yeah agreed, we def want to upgrade for both the reasons you mentioned (avoiding the hack and that we don't want to be stuck on ES 6 forever regardless)