[09:02:24] ejoseph: o/ [10:12:23] dcausse: I'm scheduling our ITC for tomorrow. Can you be ready by then? [10:13:08] gehel: sure, will do this this afternoon [10:13:17] thx [10:20:49] away: i need to fix my Gen [10:36:26] ejoseph: good luck! If all else fails, hitting it repeatedly with a spanner might fix it [10:36:34] or so I've heard [10:52:46] lunch [11:03:19] Errand+lunch [12:08:34] Hi! I have a WikibaseCirrusSearch question: is the statement_keywords field only available as a text field in elastic or is there a keyword version of it? [13:15:50] jakob_WMDE: hi, the keyword is haswbstatement (https://www.mediawiki.org/wiki/Help:Extension:WikibaseCirrusSearch#haswbstatement) [13:15:51] dcausse: you might have an answer to jakob_WMDE's question [13:17:58] dcassue: can we continue [13:18:23] gehel: lol, it didn't get to that [13:21:42] ejoseph: I'm around let's use the same meet link [13:22:15] dcausse: ah, sorry, I meant to ask whether statement_keywords is indexed as a keyword field in elasticsearch in addition to being a text field [13:23:19] jakob_WMDE: hm.. the statement_keywords is only indexed as a "keyword like" field [13:23:52] the analyzer it uses should be lowercase_keyword that does not tokenize the input text [13:25:47] jakob_WMDE: if you're not finding what you're looking for perhaps it's that it does not get indexed? [13:26:09] ok, I'm trying to run a query with terms aggregation on the field to get unique statement values from it, but getting "Fielddata is disabled on text fields by default. Set fielddata=true on [statement_keywords] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead." [13:26:40] I guess terms aggregation only works on actual keyword fields? :/ [13:27:21] yes, specifically it works only with fieldvalues which are "on" by default on keyword type [13:27:52] here we don't use the keyword type but the text type with an "keyword like" analyzer [13:28:05] alright, this was quite a hacky idea anyway. thanks! :D [13:31:32] jakob_WMDE: perhaps you could hack something with https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregations-bucket-significanttext-aggregation.html ? [13:31:53] I never tried this [13:31:58] it might be super slow tho [13:33:15] dcausse: ooh, that looks interesting. I'll give it a try, thanks! [14:16:56] greetings! Accidentally cut the (extremely long) cable to my WLAN access point. On wired for now but need to fix that sometime today before my family disowns me [14:46:06] o/ [15:09:36] mpham: we lost you, can you connect back? Or did we lose you for good (or bad)? [16:47:32] tanny411: didn't you work (and complete) this already: T299059 ? Is this a duplicate ticket or is it something different? [16:47:32] T299059: Write an Airflow job converting commons structured data dump to Hive - https://phabricator.wikimedia.org/T299059 [16:49:54] gehel: no, its different. its regarding creating an airflow job for the new table structure i created. [16:50:51] Oh, ok. Would you be the one working on it? Or is this going to be done by Data Engineering? [16:55:43] I believe Data Eng. This was delayed probably because they recently set up airflow and are working on making it work better [16:58:03] tanny411: thanks for all the info! [17:01:12] ebernhardson: inflatador and I are working to get the new eqiad elastic hosts into service this week, so it probably makes sense for us to flip on the saneitizer after we do that to reduce the work the cluster is performing? [17:01:22] (I'm guessing tuesday is when we'll bring those new hosts in, since today will be wcqs stuff) [17:01:30] ryankemper: yes that should be fine. [17:05:14] dinner [17:05:55] gehel: wrt making (some) cookbooks runnable by non-SRE, do you know if there's an actual ticket for that or if it's just one of those "SRE knows it should be done eventually but there's no formal ticket" situations? [17:06:15] I think the latter based off a cursory search but could be using the wrong search terms [17:06:31] ryankemper: T284302 [17:06:31] T284302: Rootless cookbooks/spicerack - https://phabricator.wikimedia.org/T284302 [17:06:47] * ebernhardson was searching in phab for volans and cookbook assuming it would come up :P [17:06:52] lol [17:07:11] ah of course! :P I should have known [17:07:13] thx volans [17:09:01] anytime :) [17:35:33] ryankemper / inflatador : let's cancel our meeting today, we had it last week already [17:35:48] ACK [17:35:50] gehel: inflatador: sounds good [18:56:01] Woohoo, making progress on the whole "migrating to new laptop" thing [18:56:54] i wonder when git changed remote branch checkouts, i use it so rarely (usually git review -d nnn) had to lookup how. Apparently `git fetch origin +es68:es68` creates a new local tracking branch [18:57:52] ebernhardson: I'm not quite following, what changed with remote branch checkouts? [18:58:02] ryankemper: i used to type `git checkout origin es68` and it didit [18:58:20] or `git checkout -b es68 origin es68` if you wanted to name the branch [18:59:02] Ah so for example previously `git checkout -b es68 origin es68` would create a new branch named `es68` and set it equal to `origin/es68`? [18:59:07] yea [18:59:30] yeah that new syntax looks weird [19:00:02] i supposed, compared to all the oddities of git this is minor :) [19:00:07] btw as an aside I changed my git fetch alias to just do a `git fetch --all` so I shouldn't ever run into that other `gerrit` remote problem again [19:00:23] that seems sensible, i should probably do that [19:00:28] tbh I kind of assumed fetch always fetched everything [19:00:43] cause for some personal repos i'll have both github and gitlab remotes and never though about needing to fetch both individually [19:04:42] PR for the deployment-prep servers: https://gerrit.wikimedia.org/r/c/operations/puppet/+/756643 . Not 100% on the process, but I believe this is required for puppet to recognize the new elastic VMs [19:20:20] inflatador: looks reasonable to me. For the commit message part, you can run those tests with something like `docker run -it --rm -e HOME=/tmp -e ZUUL_REF= docker-registry.wikimedia.org/releng/operations-puppet:latest' from the root of the puppet repo, but my memory is macos needs more parameters to make file permissions match up [19:21:02] * ebernhardson has a `dockerpuppet` alias that does as necessary [19:21:26] Interesting, I assume you aren't on a Mac yourself? [19:21:42] inflatador: i'm on a debian laptop, the full line i use is: 'docker run -it --rm -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro -v $PWD:/src:ro --user 0:0 -e HOME=/tmp -e ZUUL_REF= docker-registry.wikimedia.org/releng/operations-puppet:latest' [19:22:10] inflatador: because the uid the docker container uses doesn't map to my system, so i need to import my pieces [19:24:24] the problem is my solutions to these things are often hacks, maybe you'll have better ideas on how to not just overwrite things and drop it to root :) [19:35:37] hack or not, seems like a better solution than making multiple commits to fix style violations [19:48:33] OK, late lunch, back in ~1hr [20:19:18] lunch [20:42:42] AND BACK [20:44:26] run, back in 45 mins [21:03:50] back [21:58:42] you can mostly ignore the comment on wdqs/wcqs QUERY_SERVICE env, i just happen to be thinking about similar wrt logback and how having wcqs/wdqs in any name is just a giant pain [22:34:53] hmm, almost works. when wcqs gets the return from mw oauth it's redirecting to a :9999 port instead of the public port. will look [22:52:33] `wcqs` is back in `production` now [22:58:09] \o/ [23:22:14] meh, the answer to the wrong redirect is that jetty follows an outdated version of the http 1.1 spec that required all redirects to be absolute (http://server/path and not just /path) [23:22:24] so it's resolving the redirect into the internal :9999 ... fun :P [23:28:07] * ebernhardson hopes setting a host header is enough to make things happy