[00:29:56] joal: around? a while back a reported an issue with the /pageviews/top endpoint where special characters were showing up with ? [00:30:07] I think you said there was a task for that, but can't find it [00:30:16] I'm still seeing the same issue: https://wikimedia.org/api/rest_v1/metrics/pageviews/top/fr.wikipedia/all-access/2016/02/22 [00:30:45] e.g. "Sp?cial:Search" vs "Spécial:Search" [00:38:02] Analytics, Pageviews-API: Special characters showing up as question marks in /pageviews/top endpoint - https://phabricator.wikimedia.org/T145043#2618003 (MusikAnimal) [00:38:11] ^ created a new ticket just in case :) [07:28:35] (CR) Addshore: [C: 2 V: 2] Bump some dep versions [analytics/wmde/toolkit-analyzer] - https://gerrit.wikimedia.org/r/308695 (owner: Addshore) [07:28:43] (CR) Addshore: [C: 2 V: 2] New Build [analytics/wmde/toolkit-analyzer-build] - https://gerrit.wikimedia.org/r/308696 (owner: Addshore) [07:36:07] (PS1) Addshore: New Build [analytics/wmde/toolkit-analyzer-build] - https://gerrit.wikimedia.org/r/309250 [07:36:11] (CR) Addshore: [C: 2 V: 2] New Build [analytics/wmde/toolkit-analyzer-build] - https://gerrit.wikimedia.org/r/309250 (owner: Addshore) [08:10:18] Analytics, Discovery-Analysis: [REQUEST] Extract search queries from HTTP_REFERER field for a Wikibook - https://phabricator.wikimedia.org/T144714#2618396 (Tbayer) (For cross-reference, the Analytics-l thread which gave rise to this request: https://lists.wikimedia.org/pipermail/analytics/2016-September/... [08:21:47] Analytics-EventLogging, DBA, ImageMetrics: Drop EventLogging tables for ImageMetricsLoadingTime and ImageMetricsCorsSupport - https://phabricator.wikimedia.org/T141407#2618426 (Marostegui) a:Marostegui [08:32:52] Analytics-EventLogging, DBA, ImageMetrics: Drop EventLogging tables for ImageMetricsLoadingTime and ImageMetricsCorsSupport - https://phabricator.wikimedia.org/T141407#2618451 (Marostegui) Hello, We have executed the following in db1046, db1047 and dbstore1002 ``` set sql_log_bin=0 ; drop table Im... [08:34:20] joal: o/ [08:34:24] hi elukey [08:34:33] if you have time can you test yarn.w.o ? I should have fixed the links [08:36:01] elukey: it is indeed fixed for running jobs, but still has errors for jobhistory [08:36:07] elukey: url is https://yarn.wikimedia.org/jobhistory/job/job_1472219073448_35050/jobhistory/job/job_1472219073448_35050 [08:36:27] elukey: it fails because of path duplication [08:37:55] mmm interesting [08:38:00] how you end up in that link? [08:38:08] I mean, can you tell me how to repro? [08:38:20] there are tons of redirects and weird things :P [08:38:48] elukey: go to FINISHED JOBS in yarn UI, click on history link (last column on the right) of any finished job [08:39:24] got it thanks [08:39:32] I didn't see it before :) [08:39:42] elukey: Same errors come from the history link when looking into the app-master of a finished job [08:39:53] np elukey :) [08:40:12] this work you doing is really awesome, so no problem testing ! :D [08:41:20] thanks! :) [08:43:20] elukey: Given that I spend quite some time looking at hadoop jobs, you really save me many clicks :) [08:52:45] I think it is a problem with my ProxyPass rules [08:52:56] mmmmm [08:55:03] Analytics, Pageviews-API: Special characters showing up as question marks in /pageviews/top endpoint - https://phabricator.wikimedia.org/T145043#2618517 (JAllemandou) The request for that page is real, confirmed from Hive: ``` SELECT page_title, SUM(view_count) AS c FROM pageview_hourly WHERE ye... [08:56:18] Analytics: Top Pageview stats for August 27th doesn't look right - https://phabricator.wikimedia.org/T144715#2608052 (JAllemandou) See T145043 for a possible approach. [09:05:34] Analytics, Discovery-Analysis: [REQUEST] Extract search queries from HTTP_REFERER field for a Wikibook - https://phabricator.wikimedia.org/T144714#2618544 (Larsnooden) On 09/08/2016 11:10 AM, Tbayer wrote: > Tbayer added subscribers: APalmer_WMF, leila, Tbayer. Tbayer edited > projects, added Discovery-A... [09:36:22] Analytics-EventLogging, DBA, ImageMetrics: Drop EventLogging tables for ImageMetricsLoadingTime and ImageMetricsCorsSupport - https://phabricator.wikimedia.org/T141407#2618625 (Marostegui) On Friday I will check again if the tables have been recreated and get back to you @Jdforrester-WMF [09:38:50] joal: next round of tests please :) [09:40:40] elukey: Everythin works great I think [09:40:49] elukey: Thanks a lot mate :D [09:42:51] \o/ [09:43:01] It was the order of the ProxyPass directives [09:43:02] sigh [09:43:18] since I live hacked the vhost I am going to send a proper code review :P [09:43:31] elukey: I can imagine the mess [09:43:34] Thanks [09:44:39] elukey: We have an issue I think [09:45:39] elukey: unrelated to yarn UI [09:45:43] ahhh okok [09:46:05] I just spotted 2 camus run at the same time on our cluster !!!! [09:46:11] That shouldn't hapen ! [09:46:29] same thing or different one? [09:46:37] same ones, webrequest [09:47:35] maybe the error for writing files comes from there !!! [09:48:11] what the hell [09:48:26] Normally the cron checks for other run [09:48:54] :( [09:49:38] * elukey just looked to the hdfs crontab and cried [09:51:53] it seems that we have duplicates [09:52:02] elukey: :((( [09:52:22] elukey: puppet managed stuff, right? [09:53:03] I am checking atm [09:54:13] !log removed duplicates from the hdfs crontab on analytics1027 [09:54:14] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [09:54:35] joal: puppet didn't complain after that, so I guess that there is a problem with the crontab generation [09:54:54] now that I think more about this the last time that I disabled the jobs I noticed more of them [09:55:08] but I thought it was something changed during the past month [09:55:11] and I didn't check [09:55:29] because I was convinced that any inconsistency would have been removed by our dear puppet [09:55:32] BUT [09:55:38] this doesn't seem the case anymore [10:13:38] going afk for a bit and then I'll investigate joal [10:14:58] k [11:21:19] ah this is weird [11:21:30] in puppet we use the cron class to add stuff [11:21:47] add stuff == add lines to a crontab for a specific user [11:22:24] as far as I can see, puppet fixes issues when a cronjob is not listed, not if it is already there [11:23:02] I don't see anything like "make sure this entry is unique" [11:23:14] elukey: right /// [11:25:36] we could do something as stupid as crontab -l | uniq -d [11:26:07] elukey: or erase the crontab: puppet would recreate it properly I guessb [11:28:23] yeah there is also the purge option for the cron resource, but it cleans up all the crontabs for all the users [11:28:36] (at least from puppet 4.x onwards) [11:33:21] joal: I have new data for you, after I got my scoop cleaned up last night [11:33:34] it's in /user/milimetric/wmf/mediawiki/tables [11:33:41] enwiki and simplewiki [11:33:47] with the latest casts and schemas [11:33:53] milimetric: Yay :) [11:33:56] milimetric: Thanks ! [11:34:08] milimetric: I'm still having problems with the jobs :( [11:34:15] that can be the source we use for the data we send to Erik, I ran it with 20160901000000 as the date [11:34:33] ok, I'm not awake yet, this is me sleep talking, but we can brainbounce once my brain is online [11:34:51] milimetric: I'll try the job wiht simplewiki alone for erik, then back to perf test with en [11:35:01] milimetric: I'll take my break soon, so no rush on your side [11:35:33] ok, sounds like a plan, that way we can parallel check for corectness and think about perf. [11:44:04] joal https://gerrit.wikimedia.org/r/#/c/309286/1 [12:13:09] * elukey lunch! [12:49:02] https://github.com/implydata/imply-pivot has been taken down as well [13:31:09] Thanks elukey :) [13:34:04] I created the VHost on stat1001 for the current pivot on stat1002 [13:34:21] with a bit message saying that we are aware of the current situation and we'll take action [13:34:30] in case something will come up during the next months [13:34:43] my goal for today is to enable pivot.w.o [13:34:50] so you'll use it directly with LDAP auth [13:35:03] you'll have time to spot issues [13:35:07] elukey: You're the man :) [13:35:09] and I'll have time to set up a proper deploy [13:38:01] hallllooowww [13:38:29] o/ [13:39:13] joal: lets do a release deploy [13:39:17] i merged the dns change last nigt [13:39:42] ottomata: Sure [13:40:12] reading wikitech page!... [13:40:59] elukey: really? we had duplicate webrequest camus load jobs? [13:41:05] i thoguht puppet made the crons unqiue by title anyway [13:41:07] OHhhhh [13:41:12] but if the comment gets changed [13:41:15] in the crontab [13:41:16] hm [13:41:22] me toooo [13:41:31] it doesn't manage duplicates [13:41:31] resources { 'cron' [13:41:32] that is new to me! [13:41:43] I found it on the internetz today [13:41:58] ya it only knows about the uniqueness of the cron by the comment in the cron tab [13:42:01] so if it accidently gets altered [13:42:03] it loses track [13:43:24] elukey: does cron have a purge attribute? [13:43:59] ottomata: didn't find any but I was waiting for your usual magic [13:44:01] :) [13:44:11] haha [13:44:24] yeah, i don't think you can do it! :p [13:44:35] crontab and puppet are weird [13:44:53] puppet makes a unique comment in the file, and then associates the line below it with the job [13:45:03] if the comment gets manually edited [13:45:08] it will lose track of the job, and create a new one [13:45:18] it might be possible to use file_line [13:45:24] to create a cronjob in /etc/cron.d somewhere [13:45:33] but, that's gettinga little hacky [13:46:25] milimetric: Just checked one logging avro file: it seems it's not cast [13:46:56] so joal, v0.0.34 is already released, right/ [13:47:05] we are releasing 0.0.35 and i have to make a changelog entry, ja? [13:47:14] correct ottomata [13:47:28] joal, I'm pretty sure bytes is what it uses for string, because the sql definitely does cast as it selects [13:47:46] you can see it in the patch, and that's what I ran [13:47:59] milimetric: ok! Then I'll keep it cast in spark as well ! [13:48:29] it doesn't work without casting in spark? That's weird [13:48:47] I'll look around see what I can learn. [13:48:48] milimetric: when reading in spark, it says bytes [13:49:41] k, something's wrong, gonna read about how this works [13:50:00] (PS1) Ottomata: Update changelog for 0.0.35 release [analytics/refinery/source] - https://gerrit.wikimedia.org/r/309313 [13:50:06] joal: ^ [13:51:36] (CR) Joal: [C: 2 V: 2] "Merging" [analytics/refinery/source] - https://gerrit.wikimedia.org/r/309313 (owner: Ottomata) [13:54:22] ottomata: --^ [13:54:31] danke [13:54:33] building now [13:56:36] ottomata: FYI I created a VHost on stat1001 similar to yarn.w.o for pivot.w.o, pointing it to stat1002:9090. The idea is to create DNS + Varnish config and then use the website. In the meantime, I'll prepare the rest (scap, systemd unit, etc..) [13:58:53] elukey: one thing that is not as expected in yarn.w.o: timeout is too fast [13:59:21] joal: timeout? [13:59:51] milimetric, I'm reviewing your sqoop patch [13:59:52] I get a WMF error page when trying to access https://yarn.wikimedia.org/proxy/application_1472219073448_35471/mapreduce/conf/job_1472219073448_35471 [14:00:10] cool, thx [14:00:30] joal: ouch it seems a 503 [14:00:33] checking [14:00:51] elukey: +1 [14:01:03] we'd liekly run pivot itself on stat1001 eventually too [14:01:06] but that sounds cool for now [14:01:22] AH01328: Line too long, URI /proxy/application_1472219073448_35471/mapreduce/conf/job_1472219073448_35471 [14:01:25] ahhahahhaha [14:01:31] joal: --^ [14:01:33] elukey: :D [14:03:04] ahhh noooo [14:03:04] haha [14:03:09] joal: not sure if i did somehting wrong with this build [14:03:10] https://integration.wikimedia.org/ci/job/analytics-refinery-release/36/ [14:03:12] it succeeded [14:03:20] but i don't see any new tag or email to analytics-alerts [14:03:43] i did do something funky. it was originally build 35, and then i thought i had started it before you had merged the README change [14:03:45] so i stopped it [14:03:50] saw that it was actually building at the correct commit [14:03:55] and the rebuilt it as build 36 [14:04:00] maybe that doesn't work? [14:04:07] ottomata: don't know ottomata :( [14:04:08] maybe I should just resubmit a new build [14:04:17] also, i noticed that the form defaults where not totally correct [14:04:20] so i modified tem manually [14:04:28] ottomata: that should be fine [14:04:43] ottomata: emails just came in [14:05:09] joal: less nice - https://bz.apache.org/bugzilla/show_bug.cgi?id=56176 [14:05:17] oh! [14:05:25] and of course the new directive is not in the actual httpd version that we have [14:05:28] sigh [14:05:38] elukey: :( [14:05:47] hm but .35 is not in archiva.. [14:05:56] ottomata: was about to you that [14:06:06] ottomata: Have you just built, or release? [14:07:12] iu thoguth it was release [14:07:13] oh [14:07:17] but maybe the rebuild didn't do the whole thing [14:07:18] hm [14:07:22] ok gonna try again [14:07:49] this time the form defaults are correct [14:08:26] ottomata: this pattern is documented I think :D [14:09:49] the form defaults, ja [14:10:51] ah ja now uploads are happening! [14:11:15] joal: so I'd need to switch to something different than mod_substitute, maybe https://httpd.apache.org/docs/2.4/mod/mod_proxy_html.html#proxyhtmlurlmap [14:13:22] let me try that [14:14:10] elukey: I'm really sorry about that :( [14:15:31] milimetric: don't forget about --job-name param on your sqoop script :) [14:19:14] joal: I am having fun, thanks for the extensive tests :) [14:19:30] elukey: I'm just doing my usual checks :) [14:21:04] milimetric, should I look into which fields are public in MW DB? [14:25:54] ooh yeah, mforns the labsdb views [14:26:09] we can look together, I don't know where those are [14:26:35] mforns: I patched what ottomata said above, can I push or do you have more comments to submit? [14:26:57] milimetric, ok, let me finish going through the code, and I ping you? [14:27:20] mforns: I'll submit the patch then, it's only the sqoop file that changed, all else is the same [14:27:25] ok [14:27:43] (PS13) Milimetric: Script sqooping mediawiki tables into hdfs [analytics/refinery] - https://gerrit.wikimedia.org/r/306292 (https://phabricator.wikimedia.org/T141476) [14:28:13] ottomata: not sure if you saw Giuseppe's puppet change but the catalog went down from 27Mb to 1.5 :) [14:28:20] !:o [14:37:41] mforns: I found https://github.com/wikimedia/operations-software-redactatron/blob/master/scripts/cols.txt and asking in #wikimedia-labs if that's the standard [14:37:58] looks like it, since jaime just updated it last year [14:38:07] milimetric, looking [14:39:55] milimetric, looks like K is public and F is private? [14:40:04] yes [14:41:21] ok [14:42:17] milimetric, then, I think we're good, couldn't find any private field we use [14:42:33] oh I did mforns, user_email [14:42:54] and user_password_expires isn't in the redaction file at all, gonna ask about that [14:43:04] I'll send another patch when I've gone through [14:43:11] user_email? didn't know we were sqooping that, sorry [14:43:33] yeah, the fields we're sqooping are here, I didn't do a good job of minimizing it: https://gerrit.wikimedia.org/r/#/c/306292/13/bin/sqoop-mediawiki-tables [14:43:39] I'll do that now [14:44:23] ottomata: looks like we have 0.0.35 :) [14:44:57] yes, makes sense to leave out the email [14:45:32] milimetric, there's also rev_text_id [14:45:43] yep, just saw that [14:45:44] and rev_comment [14:45:51] rev_comment is fine [14:46:00] oh yea [14:46:39] milimetric, it was ar_comment, wich is also marked with F [14:46:55] and ar_text [14:47:01] rev_content_model and rev_content_format are not in the table [14:47:16] yeah, those two make sense and that means we have to change the other patches too [14:47:22] sorry, should've checked this earlier [14:50:04] ja joal! the job is still uploading though [14:50:06] to archia [14:51:49] ottomata: just sent a reivew [14:51:55] ottomata: for patching the puppet cron [14:53:27] ok great [14:53:35] good catch, i would not have remembered that [14:58:12] joal: which puppet cron? [14:58:17] camus [14:58:29] oh! [14:58:32] jenkins done, looking [14:58:50] elukey: for the checker to use the new jar [14:59:14] ahhh okok :) [14:59:41] updating symlinks building now [15:00:19] nice! that all worked! [15:00:22] (CR) Mforns: Script sqooping mediawiki tables into hdfs (15 comments) [analytics/refinery] - https://gerrit.wikimedia.org/r/306292 (https://phabricator.wikimedia.org/T141476) (owner: Milimetric) [15:00:23] yeehaw thanks madhuvishy! :D :D [15:00:30] that was def easier than the manual process [15:00:48] ottomata: most agreed ! Thanks again madhuvishy :) [15:01:25] milimetric, I commented on the previous patch, added comments for the fields we spoke about, not to forget [15:01:43] *to not forget [15:28:26] milimetric, I didn't totally understand the issues with redactation, couldn't we just sqoop from the sanitized DBs? [15:29:57] mforns: That would make it really easier :) [15:33:50] joal / mforns: those are only available in labs as far as I know [15:33:59] or they're in some weird in-between zone [15:34:08] and last time I asked it was impossible to access them [15:34:20] milimetric, ad if we sqoop out of labs? [15:34:24] *and [15:34:39] oh [15:35:28] maybe making them accessible is easier than fixing it from the other side? [15:37:19] !log deploying refinery with v0.0.35 of refinery source [15:37:21] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [15:37:29] milimetric: taskinnnnnggg? [15:37:33] coming [15:37:36] (was talking to jaime) [15:40:11] Analytics-Kanban: Switch AQS to new cluster - https://phabricator.wikimedia.org/T144497#2619503 (Nuria) [15:40:15] Analytics-Kanban, Datasets-Webstatscollector, RESTBase-Cassandra, Patch-For-Review: Better response times on AQS (Pageview API mostly) {melc} - https://phabricator.wikimedia.org/T124314#2619502 (Nuria) [15:52:41] Analytics-Kanban: Switch AQS to new cluster - https://phabricator.wikimedia.org/T144497#2619527 (Nuria) Things to have in mind: Aqs code is slightly different on new and old cluster as compression scheme is hardcoded as part of aqs setup. We need a job to load the new cluster (we will have 2 jobs for a bit... [15:53:04] Analytics-Kanban: Setup regular loading job new aqs cluster - https://phabricator.wikimedia.org/T145087#2619529 (Nuria) [15:54:33] Analytics-Kanban: Setup regular loading job new aqs cluster - https://phabricator.wikimedia.org/T145087#2619529 (Nuria) We only have loaded the per-article data, we need to load the unique devices data, top data... backfilling for every end point. [15:56:19] Analytics-Kanban: Continue New AQS Loading - https://phabricator.wikimedia.org/T140866#2619558 (Nuria) We need to load data for all endpoints. Unique devices, top data. [15:57:51] Analytics-Kanban: Load top data into new AQS cluster - https://phabricator.wikimedia.org/T145089#2619559 (Nuria) [15:58:56] Analytics-Kanban: Continue New AQS Loading - https://phabricator.wikimedia.org/T140866#2479035 (Nuria) [15:58:59] Analytics-Kanban, Datasets-Webstatscollector, RESTBase-Cassandra, Patch-For-Review: Better response times on AQS (Pageview API mostly) {melc} - https://phabricator.wikimedia.org/T124314#2619575 (Nuria) [16:01:43] Analytics-Kanban: Load top article data into new AQS cluster - https://phabricator.wikimedia.org/T145089#2619595 (Nuria) [16:06:43] Analytics-Kanban: Setup regular loading jobs new aqs cluster (per-article, top and unique devices) - https://phabricator.wikimedia.org/T145087#2619603 (Nuria) [16:26:34] milimetric, mforns : For qulity check --> val df = sqlContext.read.parquet("/user/joal/mwhist_2/denorm/") [16:28:59] Analytics: Top Pageview stats for August 27th doesn't look right - https://phabricator.wikimedia.org/T144715#2608052 (Milimetric) One idea is to take advantage of the webrequest -> pageview_hourly transformation, which already groups by hour. We could add a column to pageview_hourly called "distinct_user_ag... [16:43:11] Analytics-Kanban: Redact data so it can be public - https://phabricator.wikimedia.org/T145091#2619672 (Nuria) [16:44:41] Analytics, Pageviews-API, WMUA-Tech: No page view stats for wikimedia chapters sites - https://phabricator.wikimedia.org/T145033#2619701 (Nuria) [16:44:45] Analytics-Kanban: Count pageviews for all wikis/systems behind varnish - https://phabricator.wikimedia.org/T130249#2619704 (Nuria) [16:44:52] Analytics, Pageviews-API, WMUA-Tech: No page view stats for wikimedia chapters sites - https://phabricator.wikimedia.org/T145033#2617636 (Nuria) This is a known issue, closing as duplicate. [16:48:15] Analytics, Operations: Can't log into https://piwik.wikimedia.org/ - https://phabricator.wikimedia.org/T144326#2619710 (Nuria) Moving to radar as ops are the ones that could shed some light here. [16:50:46] running home! [16:51:04] a-team - I just merged the last apache changes for yarn [16:51:18] it should be correct and faster than before [16:51:34] if you see issues please wait a bit because Varnish might have cached part of the content [16:51:50] elukey, ok I'll try in a while [17:10:29] ebernhardson: yt? [17:15:45] all right merged the varnish config for pivot [17:15:52] tomorrow I'll add the new domain name [17:16:06] nuria_: yup [17:16:08] and it should be ready to use (the instance that Andrew is running in screen of course) [17:18:14] Analytics-Cluster, Operations: Migrate titanium to jessie (archiva.wikimedia.org upgrade) - https://phabricator.wikimedia.org/T123725#2619776 (Ottomata) Ok! DNS has been merged, and we just did our first refinery release using jenkins and archiva. ALL IS WELL! [17:19:29] Analytics-Kanban, EventBus, Wikimedia-Stream: Kasocki Prototype - https://phabricator.wikimedia.org/T145095#2619783 (Ottomata) [17:23:08] * elukey afk! o/ [17:27:44] Analytics, Pageviews-API: Special characters showing up as question marks in /pageviews/top endpoint - https://phabricator.wikimedia.org/T145043#2618003 (mforns) It looks like a very interesting idea! Thoughts on it: 1) The mobile pageviews generated in countries whose ISP proxies all requests, which en... [17:33:28] Analytics-Cluster, Operations: Migrate titanium to jessie (archiva.wikimedia.org upgrade) - https://phabricator.wikimedia.org/T123725#2619847 (MoritzMuehlenhoff) Nice! Let's keep titanium around for another two weeks just in case we need to track something down that wasn't noticed. [17:53:43] hey mforns_brb [18:00:20] Analytics, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2619979 (Ottomata) [18:00:50] Analytics, Pageviews-API: Special characters showing up as question marks in /pageviews/top endpoint - https://phabricator.wikimedia.org/T145043#2618003 (Nuria) >whose ISP proxies all requests, which end up having the same user agent. I mmm... an example for this? ISPs might proxy requests but (while i h... [18:02:33] Analytics, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2619979 (Pchelolo) @Ottomata Actually, could you make this a separate micro-module in npm so that #changeprop could do the same thing? [18:03:29] ebernhardson: back, sorry. [18:03:38] Analytics, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2620004 (Ottomata) > or as a separate node module for use with node-rdkafka, Sounds like you like option 2 the best, I think I concur! :) [18:04:19] ebernhardson: Tilman point me to this cause we were talking about ways to calculate retention and this piece of code basically does that: https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.searchSatisfaction.js#L216 [18:04:38] Analytics, ChangeProp, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2620010 (Ottomata) [18:05:16] ebernhardson: I have pointed out some issues that i see in this ticket: https://phabricator.wikimedia.org/T119352 [18:14:26] ottomata: how can i see hdfs crontab on 1027? su hdfs ask me for a pw [18:14:29] hey mil [18:14:32] hey milimetric [18:14:36] tab miss [18:14:57] vetting time? [18:15:00] yes [18:15:23] to the cave! [18:15:46] milimetric, cave-2? [18:15:59] k [18:17:22] ottomata: ah wait maybe this is on puppet [18:48:27] elukey, I still get linked to a 404 :[ [18:57:31] nuria_: hi sorry wa sin meeting [18:57:34] sudo -u hdfs crontab -l [18:58:54] ottomata: ah sorry, i see listing it works w/o pw [18:59:05] no nuria [18:59:07] you can't su hudfs [18:59:08] ottomata: i did not think i had sudo [18:59:10] you have to sudo -u hdfs [18:59:15] you can sudo -u hdfs [18:59:16] user only [18:59:16] ottomata: k [19:00:06] ottomata: many thanks [19:00:26] sho thang :) [19:18:44] mforns: I think it is Varnish :( [19:19:00] when I checked the access logs I wasn't seeing your request going through [19:19:07] so it must have been cached [19:21:28] elukey: I experience the same [19:21:59] elukey: two ways to access application master: Click on the job link - Then on the job page, go to the ApplicationMester link - This works [19:22:27] other way that fail is to go straight to the application master link at the end of the row (last column) [19:24:16] I'm gone for tonight a-team, see you tomorrow ! [19:24:26] bye joal! [19:24:30] nite man [19:24:33] elukey: to bypass varnish you can add some random string to url : http://some?v=6986986 and see if url really works [19:24:33] elukey, ok [19:24:38] elukey: tomorrow taht is [19:24:40] *that [19:59:16] mforns: /user/milimetric/wmf/mediawiki/tables [20:01:06] (CR) Milimetric: [C: -1] "we found some problems, especially in the historified fields. The page and user histories seem correct but the join is misaligned somehow" (3 comments) [analytics/refinery/source] - https://gerrit.wikimedia.org/r/307903 (owner: Milimetric) [20:04:26] (PS1) Nuria: Map null count values to zeros in output [analytics/aqs] - https://gerrit.wikimedia.org/r/309386 (https://phabricator.wikimedia.org/T144521) [20:06:38] (CR) Nuria: [C: -1] "Formatting is off." [analytics/aqs] - https://gerrit.wikimedia.org/r/309386 (https://phabricator.wikimedia.org/T144521) (owner: Nuria) [20:12:06] (CR) Milimetric: "Fixed the small things, added TODOs where I was lazy. As for redacting any of the fields, I think we should piggyback on a pre-redacted s" (4 comments) [analytics/refinery] - https://gerrit.wikimedia.org/r/306292 (https://phabricator.wikimedia.org/T141476) (owner: Milimetric) [20:12:30] (PS14) Milimetric: Script sqooping mediawiki tables into hdfs [analytics/refinery] - https://gerrit.wikimedia.org/r/306292 (https://phabricator.wikimedia.org/T141476) [20:12:51] yeah will double check tomorrow, I am pretty sure that Varnish cached 404s and this is the issue.. [20:12:58] will figure out how to clean up the cache :) [20:13:03] Analytics, Discovery-Analysis: [REQUEST] Extract search queries from HTTP_REFERER field for a Wikibook - https://phabricator.wikimedia.org/T144714#2620800 (Tbayer) >>! In T144714#2618544, @Larsnooden wrote: > On 09/08/2016 11:10 AM, Tbayer wrote: >> Legal issues: By default we need to treat referrers as... [20:22:55] (PS2) Nuria: Map null count values to zeros in output [analytics/aqs] - https://gerrit.wikimedia.org/r/309386 (https://phabricator.wikimedia.org/T144521) [20:24:17] Analytics-Kanban, Patch-For-Review: Reduce rate of events coming from datepicker - https://phabricator.wikimedia.org/T144856#2620842 (Nuria) Open>Resolved [20:24:31] Analytics-Dashiki, Analytics-Kanban, Patch-For-Review: Sort tabs layout alphabetically - https://phabricator.wikimedia.org/T144322#2620843 (Nuria) Open>Resolved [20:24:50] Analytics-Kanban: Update camus-partition-checker to be more resilient - https://phabricator.wikimedia.org/T144716#2620844 (Nuria) Open>Resolved [20:31:28] Analytics-Kanban, Operations, Performance-Team, Traffic: Preliminary Design document for A/B testing - https://phabricator.wikimedia.org/T143694#2620857 (Nuria) [20:40:17] Analytics, Operations: Can't log into https://piwik.wikimedia.org/ - https://phabricator.wikimedia.org/T144326#2620872 (Tbayer) @Milimetric Are you able to log in with the credentials for the user "piwik", too? [20:42:27] mforns: I can look at your reportupdater CRs tomorrow, run out of time today, sorry. [20:42:33] milimetric: am trying differential out [20:42:38] want to try reviewing this ? [20:42:39] https://phabricator.wikimedia.org/D340 [20:42:54] nuria_, ok, but those patches are low priority, don't worry [20:43:11] sure, looking [20:45:47] milimetric: not totally sure how this works, merging might be only done via arc land on the CLI [20:46:07] yeah... I just accepted the patch [20:46:27] so I guess someone has to arc land it? I donno :) [20:46:39] ok [20:59:27] Analytics, Operations: Can't log into https://piwik.wikimedia.org/ - https://phabricator.wikimedia.org/T144326#2620944 (Milimetric) @Tbayer: curious, I didn't see a piwik user. So I created one, gave it view access to all sites, and stored the credentials in the same file: /home/milimetric/piwik.creden... [21:11:50] Analytics, ChangeProp, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2620985 (mobrovac) [21:12:20] Analytics, ChangeProp, EventBus, Wikimedia-Stream: Write node-rdkafka event.stats callback that reports stats to statsd - https://phabricator.wikimedia.org/T145099#2619979 (mobrovac) [21:33:16] Analytics-Kanban: Count pageviews for all wikis/systems behind varnish - https://phabricator.wikimedia.org/T130249#2621016 (Sadads) @Nuria Cool! Is there a timeline for this: next couple sprints? [21:35:23] ottomata: joal :D Glad it works :) [22:01:11] Analytics, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621117 (Ottomata) [22:15:18] Analytics, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621117 (Paladox) What test's would you like run? [22:15:47] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621158 (Paladox) [22:16:55] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621160 (Ottomata) mocha or maybe better, npm test [22:18:26] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621167 (Paladox) Yep, we can do npm test, but just to let you know jenkins is currently broken in diff... [22:40:25] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621287 (mmodell) it should now be set up to run `npm test` [22:41:41] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621295 (Paladox) Thanks @mmodell [22:45:57] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621308 (mmodell) @ottomata: running `npm test` locally on a checkout of this repo throws a bunch of er... [22:51:12] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621117 (mobrovac) How about using Travis for now since the repo is on GitHub? [23:15:06] Analytics-Kanban: Count pageviews for all wikis/systems behind varnish - https://phabricator.wikimedia.org/T130249#2621456 (Nuria) @sadads: ETA is the end of next quarter, that is, end of December. [23:29:42] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621501 (mmodell) @mobrovac I think that is the status quo for now. This task, however, is about differ... [23:49:30] Analytics, Continuous-Integration-Infrastructure, Differential, EventBus, Wikimedia-Stream: Run Kasocki tests in Jenkins via Differential commits - https://phabricator.wikimedia.org/T145140#2621577 (Ottomata) Yeah, npm test 'works' in travis now because `.travis.yml` sets up the KAFKA_HOME bi...