[07:14:04] (03CR) 10Joal: [V: 032 C: 032] "LGTM ! Merging" [analytics/refinery] - 10https://gerrit.wikimedia.org/r/424626 (https://phabricator.wikimedia.org/T191645) (owner: 10Nuria) [07:15:05] !log upgrade kafka burrow on kafkamon* [07:15:06] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log [07:15:14] kafka burrow 1.0 deployed! [07:15:20] Morning elukafkey :) [07:16:21] morningggg [07:21:01] (03PS1) 10Joal: Correct default memory of oozie launcher [analytics/refinery] - 10https://gerrit.wikimedia.org/r/425003 [07:22:14] PROBLEM - Kafka MirrorMaker main-eqiad_to_jumbo-eqiad max lag in last 10 minutes on einsteinium is CRITICAL: CRITICAL - scalar(max(max_over_time(kafka_burrow_partition_lag{group=kafka-mirror-main-eqiad_to_jumbo-eqiad} [10m]))): 121736697.0 100000.0 https://grafana.wikimedia.org/dashboard/db/kafka-mirrormaker?var-datasource=eqiad%2520prometheus%252Fops&var-mirror_name=main-eqiad_to_jumbo-eqiad [07:22:37] ah right these alarms :D [07:23:36] silencing since the burrow metrics are horrible now [07:27:38] it will probable take a bit to burrow to get back to its original state [07:28:11] this is interesting - is burrow going to loose its memory after each restart? [07:28:28] this use case is tricky since it was a major upgrade [07:31:22] https://github.com/linkedin/Burrow/wiki/Configuration#storage [07:31:32] it seems that the only supported one is "in memory" [07:31:41] so afaics not resilient to restarts [07:31:58] hm [07:32:58] joal: https://grafana.wikimedia.org/dashboard/db/kafka-consumer-lag?orgId=1&from=now-3h&to=now&var-datasource=eqiad%20prometheus%2Fops&var-cluster=main-eqiad&var-topic=All&var-consumer_group=All&panelId=1&fullscreen [07:33:32] so main-eqiad is of course the one that suffers the most when burrow is restarted [07:33:40] in this case, I can see two patterns: [07:34:07] 1) after the upgrade, some cgroups wend up to a constant lag - this might be 0.1 vs 1.0 logic [07:34:53] 2) after the upgrade/restart, some cgroups went up to a gigazillion lag and then slowly ramped down once the burrow's evaluator started to store more and more metrics about how those cgroups were doing [07:35:05] I'd expect 2) to happen every time we restart [07:35:26] not a big deal of course,but we'll need to silence alarms :D [07:43:08] I hear that elukey [07:43:25] elukey: wouldn't it be nice to add a sore to burrow? [07:45:19] joal: it would yes, now that we are very close to what burrow upstream is we could influence their development cycles (maybe) [07:45:28] providing feedback etc.. [07:45:44] so metrics have stabilized now [07:46:11] and I noticed that now the only metrics that stay up to a constant lag are mirror maker ones [07:46:11] great elukey [07:46:40] hm - great for metrics stabilization, not for MM being behind ... [07:48:49] all refreshlinks related [08:49:48] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4115944 (10ema) >>! In T187014#4113030, @Nuria wrote: > @ema: on our end we just look at the ip passed along via varnishkafka to geolocate,... [10:10:09] 10Analytics-Tech-community-metrics, 10Developer-Relations: Inconsistent numbers between number widgets and list widgets; some accounts counted twice - https://phabricator.wikimedia.org/T184741#4116134 (10Aklapper) [10:10:33] 10Analytics-Tech-community-metrics, 10Developer-Relations: Inconsistent numbers between number widgets and list widgets; some accounts counted twice - https://phabricator.wikimedia.org/T184741#3893944 (10Aklapper) Other example: 1. Go to https://wikimedia.biterg.io/app/kibana#/dashboard/Gerrit for timeframe... [10:19:53] 10Analytics-Tech-community-metrics: Affiliations/enrollments not correctly synced between user data in database and frontend indices - https://phabricator.wikimedia.org/T191779#4116189 (10Aklapper) p:05Triage>03Normal [10:21:47] 10Analytics-Tech-community-metrics: Affiliations/enrollments not correctly synced between user data in database and frontend indices - https://phabricator.wikimedia.org/T191779#4116189 (10Aklapper) [10:24:53] 10Analytics-Tech-community-metrics: Affiliations/enrollments not correctly synced between user data in database and frontend indices - https://phabricator.wikimedia.org/T191779#4116240 (10Aklapper) [10:24:55] 10Analytics-Tech-community-metrics, 10Developer-Relations (Apr-Jun-2018): Advertise wikimedia.biterg.io more widely in the Wikimedia community - https://phabricator.wikimedia.org/T179820#4116239 (10Aklapper) [10:25:39] 10Analytics-Tech-community-metrics: Affiliations/enrollments not correctly synced between user data in database and frontend indices - https://phabricator.wikimedia.org/T191779#4116189 (10Aklapper) [11:27:56] 10Analytics-Tech-community-metrics, 10Developer-Relations (Jan-Mar-2018): Investigate how to identify our code contributors to on-wiki code (gadgets, templates, modules) on a WMF site - https://phabricator.wikimedia.org/T190164#4116376 (10Aklapper) Note to myself: AFAIK Quarry does not yet allow running cross-... [11:35:12] 10Analytics, 10Analytics-Kanban, 10Patch-For-Review, 10User-Elukey: Add the prometheus jmx exporter to all the Zookeeper daemons - https://phabricator.wikimedia.org/T177460#4116389 (10elukey) [11:35:57] zookeeper metrics fully migrated to prometheus [11:36:01] including alerts [11:44:15] (03Abandoned) 10Joal: Set up memory for mediawiki-history-reduced [analytics/refinery] - 10https://gerrit.wikimedia.org/r/424630 (owner: 10Joal) [11:58:28] (03PS2) 10Joal: Update spark jobs to use hive context [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/415812 (https://phabricator.wikimedia.org/T159962) [12:06:52] (03PS3) 10Joal: Update oozie spark jobs to using spark2 with hive [analytics/refinery] - 10https://gerrit.wikimedia.org/r/415324 [13:18:35] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4116636 (10Ottomata) > No, X-Client-IP is either: ...ehhh wha? We used to collect XFF on the webrequest side, and then parse it to get `ip... [13:20:24] ottomata: o/ [13:20:32] morningggg [13:21:11] whenever you are caffinated and bootstrapped I'd need to have a chat with you about the new Burrow 1.0 metrics [13:21:17] and the mirror maker alerts [13:28:25] (03CR) 10Ottomata: "Hm, haha, I'd be fine with merging this too, but I just thought of an even BETTER way! python/refinery/util.py has HiveUtils, which has f" [analytics/refinery] - 10https://gerrit.wikimedia.org/r/419953 (owner: 10EBernhardson) [13:29:28] 10Analytics, 10Analytics-Kanban, 10Services (watching), 10User-Elukey: Upgrade Kafka Burrow to 1.0 - https://phabricator.wikimedia.org/T188719#4116671 (10elukey) [13:29:57] 10Analytics, 10Analytics-Kanban, 10Services (watching), 10User-Elukey: Upgrade Kafka Burrow to 1.0 - https://phabricator.wikimedia.org/T188719#4017205 (10elukey) [13:36:39] joal: FYI, i have a patch going in spark to let us do alter table change column [13:36:45] but, first i gotta get spark to compile......... [13:36:49] but i think it should work [13:38:34] wow internet v slow at cafe, heading home! :) brb [14:15:47] joal: , yt? [14:16:25] elukey: ottomata: Question about Kafka. I have some eventlogging data that I need to replay in to coal -- there's a period from 3/20-4/2 where we were accidentally processing both regular NavigationTiming samples and oversamples, when we should have been discarding the oversamples. I _think_ that the easiest way to handle that (given that coal is designed to read from Kafka) is going to be 1) pull from the eventlogging database 2) [14:16:25] write to a new temp Kafka topic 3) run a special instance of coal that reads from that new topic. [14:17:10] Questions are, does this seem reasonable? If so, is there an appropriate Kafka instance? (I'm happy to rate-limit writes however you wish.) [14:18:02] marlier: ya sounds fine i think, use the same kafka jumbo-eqiad cluster, and use a topic name that makes sense, that makes it clear that it is for temporary and for coal / NavigationTiming [14:18:13] maybe coal_replay_temp or something i dunno :) [14:18:23] or [14:18:41] NavigationTiming_replay_temp. might be nice to use the coal_ one in case you need to reuse it for somethign else [14:18:56] Nice, that works. [14:19:05] topics stick around until we delete them manually, they generally don't cause any problems just sitting there, but it is nice to have it as clean as possible [14:19:12] Absolutely [14:19:20] Was thinking 50/sec as a write rate limit? [14:24:41] marlier: shoudl be fine, you can probably go way higher than that [14:24:56] our EL throughput limits are about el processors, not kafka [14:25:01] if you are producing to kafka, you should be able to do a lot [14:25:08] that cluster is doing 150K / sec on average [14:27:46] ottomata: whenever you have time let's chat about the mirror maker alarms [14:28:21] ottomata: Ah, nice, didn't realize the EL bottleneck was at the processing side. I'll turn it up. Thanks! [14:30:46] elukey: sure whaaas up? [14:30:49] burrow 1.0?~ :) [14:31:26] yeah :) [14:31:58] so there are now metrics for the main->jumbo cgroup that are showing a constant lag, all related to changeprop topics [14:32:05] that we don't mirror right? [14:32:12] that's right [14:32:17] we probably did at some point for a sec [14:32:27] so all the prometheus aggregation sum(avg(etc.. fire now [14:32:30] but, hm, not last week [14:32:41] i thought that the consumer groups expired after a week [14:32:54] well, cgroup/topic assigments [14:33:01] maybe it is just cgroups! [14:33:02] I wanted to ask you the same, not sure why it is still reporting old data [14:33:05] that would be a shame [14:33:38] https://grafana.wikimedia.org/dashboard/db/kafka-consumer-lag?panelId=1&fullscreen&orgId=1&var-datasource=eqiad%20prometheus%2Fops&var-cluster=main-eqiad&var-topic=All&var-consumer_group=All&from=now-3h&to=now [14:33:57] the worst one is for changeprop-refreshlinks [14:35:16] 10Analytics, 10Analytics-Wikistats: Upgrading Wikistats 2.0 footer UI/design - https://phabricator.wikimedia.org/T191672#4116908 (10mforns) Good work :] Kudos! I think the footer you designed has improvements, in my opinion: - It looks better, meaning, I think the reader would be more likely to have a look at... [14:35:20] hm, ya am not sure elukey [14:35:25] it shouldn't count as lag [14:35:35] but, i don't know about how kafka expires its groups/topic assignment [14:35:43] i know we have expiration set to at least a week [14:35:57] i think the default is like a day, which caused us problems in the past in EL when we were doing maintenance [14:36:02] (or somethign) [14:39:27] ottomata: was there any test to mirror change prop topic last week? I don't recall [14:40:41] maybe we could tune the alert to skip the changeprop topics [14:42:28] elukey: no i didn't do it [14:42:59] but, maybe kafka never expires topic partitions? only totally inactive consuer groups.. [14:45:53] topic partitions? [14:46:30] commits to specific partitions [14:46:34] elukey: googling seems to confirm [14:46:49] ahh okok [14:46:53] kafka will delete consumer group offsets only if there has been no commits from a consumer withing offset.retention.minutes [14:47:08] so, if we unsubscribe from a topic [14:47:12] but the group keeps comittied [14:47:17] the offests for that topic will never increase [14:47:22] but they will remain in kafka [14:47:24] for that group [14:47:26] hm [14:47:47] so what to do? is there a way to maybe ignore any offsets that haven't changed in over a week (or our value of offset.retention.minutes)? [14:50:29] https://cwiki.apache.org/confluence/display/KAFKA/KIP-211%3A+Revise+Expiration+Semantics+of+Consumer+Group+Offsets would fix ^ [14:51:36] ah now I get it - the mirror maker cgroup does not pull anymore change-prop topics, but the fact that it still exists doing other things prevents its commits from being deleted [14:51:42] like the changeprop ones [14:52:06] exactly [14:52:56] Hey ottomata [14:53:19] heyyyy, was gonna ask for intellij help, buuut stack overflow may have helped me...compiling now mayyybe [14:53:21] I've seen your message about spark patch [14:53:31] That's super great :) [14:53:40] ottomata: I have questions about that though [14:54:11] I am trying something like kafka_burrow_partition_lag{group="kafka-mirror-main-eqiad_to_jumbo-eqiad", topic=~".*(?!change-prop).*"} to temp fix the alarms but no joy [14:54:11] ottomata: My understanding was that from spark 2 onward, native-spark was used [14:55:20] ah !~ [14:56:06] ottomata: kafka_burrow_partition_lag{group="kafka-mirror-main-eqiad_to_jumbo-eqiad", topic!~".*change-prop.*"} [14:56:15] what do you think as temp fix for the mm alerts? [14:56:53] elukey: i think prometheus has !~ no? [14:56:55] ottomata: I'm interested to see the patch :) [14:57:01] you can negative regex match without making the regex itself negative [14:57:17] oh hah [14:57:21] you just noitced [14:57:21] nice [14:57:23] elukey: hmmm [14:57:35] i guess that's fine, but kinda annoying [14:57:42] hm [14:58:09] I know :( [14:58:13] i guess we could add a parameter to mirror::alerts for blacklist topics? [14:58:15] that'd be fine i guess [14:58:21] yeah [14:58:29] then we can think about something else [14:58:34] would be better if we could think of an amazing prometheus query that would exclude offset values that haven't changed in over a week [14:58:37] the alarms are downtimed now since they were firing [14:58:47] yep [14:59:48] joal: https://gist.github.com/ottomata/19ca33c4d39318ad358efe96b94ef38f [14:59:53] (we've done this before :p ) [15:00:48] right now i just want to compile and run tests, if i get that far i'll write tests, and then submit a patch to spark [15:01:38] Ah ottomata - This doesn't submit the request to hive [15:01:45] fdans: yoohoo [15:02:00] riiiht, patch to spark to let us do alter table change column [15:03:16] 10Analytics, 10Analytics-Kanban, 10Patch-For-Review, 10User-Elukey: Add the prometheus jmx exporter to all the Zookeeper daemons - https://phabricator.wikimedia.org/T177460#4117137 (10Ottomata) a:03elukey [15:11:18] (03CR) 10Ottomata: [C: 031] Correct default memory of oozie launcher [analytics/refinery] - 10https://gerrit.wikimedia.org/r/425003 (owner: 10Joal) [15:17:13] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4117194 (10mbaluta) >>! In T187014#4111935, @ema wrote: >>>! In T187014#4111691, @mbaluta wrote: >> If you provided IP address of our server... [15:52:04] (03CR) 10Mforns: Label map and top metrics with the month they belong to (031 comment) [analytics/wikistats2] - 10https://gerrit.wikimedia.org/r/423144 (https://phabricator.wikimedia.org/T182990) (owner: 10Amitjoki) [15:57:55] 10Analytics, 10Analytics-Wikistats: Upgrading Wikistats 2.0 footer UI/design - https://phabricator.wikimedia.org/T191672#4117348 (10sahil505) Hey @mforns, thanks a lot for your feedback. > Reduce the brightness of the section titles (About us, Contributing, Community), to add more contrast, because, they won... [16:18:36] (03PS1) 10Joal: Add HiveServer to spark-refine for schema changes [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/425084 [16:29:39] (03CR) 10Mforns: "Oh, I see. You removed it because you created anoter change for the other task that I created, right?" [analytics/wikistats2] - 10https://gerrit.wikimedia.org/r/423144 (https://phabricator.wikimedia.org/T182990) (owner: 10Amitjoki) [16:53:56] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4117606 (10ema) >>! In T187014#4116636, @Ottomata wrote: > ...ehhh wha? We used to collect XFF on the webrequest side, and then parse it to... [16:59:38] (03CR) 10Ottomata: Add HiveServer to spark-refine for schema changes (032 comments) [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/425084 (owner: 10Joal) [17:07:06] (03PS14) 10Amitjoki: Label map and top metrics with the month they belong to [analytics/wikistats2] - 10https://gerrit.wikimedia.org/r/423144 (https://phabricator.wikimedia.org/T182990) [17:10:54] (03CR) 10Mforns: [V: 032 C: 032] "LGTM!" [analytics/wikistats2] - 10https://gerrit.wikimedia.org/r/423144 (https://phabricator.wikimedia.org/T182990) (owner: 10Amitjoki) [17:21:20] 10Analytics, 10Analytics-Wikistats, 10Patch-For-Review: Add UI in mobile view to switch to table view - https://phabricator.wikimedia.org/T191019#4117716 (10Amitjoki) a:05Amitjoki>03None [17:25:42] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4117734 (10BBlack) Right. There was a time in the past when Zerowiki definitely provided some useful data on OperaMini (and also Nokia?) pr... [17:26:46] 10Analytics, 10Analytics-Data-Quality, 10Analytics-Kanban, 10New-Readers, and 4 others: Opera mini IP addresses reassigned - https://phabricator.wikimedia.org/T187014#4117741 (10BBlack) Ping @DFoy - might know better about when OperaMini proxy data dropped from the Zero data, I don't have any good insight... [17:44:07] * elukey off! [17:44:55] 10Analytics, 10Analytics-Wikistats, 10Patch-For-Review: Display of radio buttons in Wikistats 2 is somewhat confusing - https://phabricator.wikimedia.org/T183185#4117800 (10mforns) @Milimetric Any thoughts? [17:44:58] Bye elukey [17:49:23] elukey: sorry didn't realize i was disconnected here! [17:51:07] ottomata: problems with hive class versions between the one we need for jdbc and the ones used for spark [17:51:25] elukey: i'm not sure what is wrong in your email, it looks like it is wokring? [17:51:30] joal: eh? [17:52:25] ottomata: 2 different versions of hive-jdbc [17:52:48] we can't use the spark one? [17:53:01] ottomata: I have a version-mismatch type of error [17:55:09] ottomata: to be precise: Required field 'client_protocol' is unset [17:57:00] ottomata: Every stack-overflow comment I see tell me versions must match :( [17:58:07] ottomata: And if I use the jar first in spark, I have spark issues, obviously [17:58:10] :( [17:58:12] MEHHHHH ! [17:58:22] 10Analytics, 10Analytics-Wikistats: Add Vue Filters to make the code clean and use them as necessary - https://phabricator.wikimedia.org/T191824#4117866 (10Amitjoki) [18:01:48] 10Analytics, 10Analytics-Wikistats: Add Vue Filters to make the code clean and use them as necessary - https://phabricator.wikimedia.org/T191824#4117879 (10Amitjoki) [18:05:01] 10Analytics, 10Analytics-Wikistats: Add Vue Filters to make the code clean and use them as necessary - https://phabricator.wikimedia.org/T191824#4117888 (10Amitjoki) [18:05:14] 10Analytics, 10Analytics-Wikistats: Add Vue Filters to make the code clean and use them as necessary - https://phabricator.wikimedia.org/T191824#4117892 (10mforns) Sounds good @Amitjoki please, go ahead! [18:06:04] 10Analytics, 10Analytics-Wikistats: Add Vue Filters to make the code clean and use them as necessary - https://phabricator.wikimedia.org/T191824#4117895 (10Amitjoki) Thanks @mforns! :) [18:12:27] joal alternative 2: [18:13:16] import sys.process._ [18:13:37] "hive -e 'ALTER TABLE ...' ".! [18:14:30] ottomata: I think I'd rather have a 1.6 module than an ugly system call :( [18:15:07] haha [18:15:14] kind of equivalent ugliness to me [18:15:23] ottomata: Looks like I have a working setting [18:15:28] oh ok cool [18:15:35] ottomata: Still need to investigate, but better each time [18:19:58] 10Analytics, 10Analytics-Wikistats: Adding ranks to the map tooltip - https://phabricator.wikimedia.org/T191141#4117905 (10Amitjoki) @mforns yes. The ranking use case has been covered in the table view, but I think it is double work if the user quickly wanted to know. Also it is a lot more easier to just move... [18:27:11] ottomata: About passing connection, I'm not a fan - It's really small calls to hive, and the process is not thread-safe [18:29:55] hm [18:30:00] aye and those will be executed in threads [18:30:01] ok joal [18:30:18] ottomata: still one more change [18:40:59] hey joal, I'm writing oozie for page previews, should I replicate the pageview_whitelist_check logic in page previews? [18:41:19] mforns: I don't know ! [18:41:52] maaan, you failed me, I lost faith [18:41:56] xD [18:42:00] :D [18:42:24] ok, will do it without while I ask in the task, thanks :] [18:46:41] mforns: I can see advantages of having it, but it's also overkill :( [18:47:02] yea ok, we can discuss it PS tomorrow maybe? [18:47:08] Sounds good :) [18:47:16] with da teem [18:47:40] I don't mind doing it or not [19:06:59] Yay ottomata ! Success !! [19:11:47] yeah! [19:11:47] awesome! [19:12:11] (03PS2) 10Joal: Add HiveServer to spark-refine for schema changes [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/425084 (https://phabricator.wikimedia.org/T159962) [19:12:22] ottomata: may I let you test as well, just to be sure? [19:12:43] ottomata: I have added the command line trick in the commit message [19:12:51] ottomata: --^ [19:15:55] joal: https://github.com/apache/spark/pull/21012 :) [19:16:07] k will test now [19:16:44] great patch ottomata :) [19:16:45] joal: do you have jar on stat1005 already? [19:16:54] ottomata: stat1004 [19:17:02] k [19:17:28] /home/joal/code/refinery-source/refinery-job/target/refinery-job-0.0.60-SNAPSHOT.jar [19:17:31] ottomata: --^ [19:17:35] great [19:17:36] thanks [19:20:59] joal i am getting We have to fall back to the table schema from Hive metastore which is not case preserving. [19:21:02] but i think that is probably fine [19:21:09] we could probably reload the table in spark sql after we alter [19:21:22] but, it seems to work! [19:21:31] hm - I hadn't seen that ottomata [19:21:36] oh i do that [19:21:36] // Refresh Spark's metadata about this Hive table. [19:21:36] spark.catalog.refreshTable(tableName) [19:21:37] hm [19:22:47] ottomata: I tested using eventbus, didn't have any warn [19:22:48] hm, joal welp, it works! [19:22:56] joal: you probably didn't get it to do an alter [19:22:58] change column [19:23:02] Very true :) [19:23:05] need an example where a new field comes into a struct [19:23:11] Right [19:23:27] 18/04/09 19:20:01 INFO DataFrameToHive: Running Hive DDL statement: [19:23:27] ALTER TABLE `otto`.`AdvancedSearchRequest` [19:23:28] CHANGE COLUMN `event` `event` struct<`filetype`:boolean,`hastemplate`:boolean,`intitle`:boolean,`not`:boolean,`or`:boolean,`phrase`:boolean,`plain`:boolean,`subpageof`:boolean,`inlanguage`:boolean> [19:23:33] Ok great - I'm happy it works - It's a less ugly solution than the other 2! [19:23:42] ya! [19:23:44] great [19:23:54] ok super [19:24:00] (03CR) 10Ottomata: [C: 031] "Tested and works for me!" [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/425084 (https://phabricator.wikimedia.org/T159962) (owner: 10Joal) [19:24:09] ottomata: tomorrow, big deploy day? [19:24:21] Or do we wait more? [19:26:06] joal: might as well! [19:26:18] joal: you saying goodnight soon? we could do now... [19:26:30] ottomata: Yeah, end of day for me [19:26:31] ok [19:26:33] lets do tomorrow [19:26:37] ottomata: great [19:26:50] ottomata: What time do you plan on starting? [19:27:10] ottomata: I need to catch Lino at school at 4pm CEST [19:27:24] Question is if we can start to have most done before [19:28:17] joal: prob 9am here [19:28:45] i can prob get up a bit earlier and get on [19:28:51] should that be enough time? [19:28:58] i think that's 2pm for you [19:28:58] hm [19:28:59] maybe not [19:29:18] ottomata: We won't have that much done before standup - Let's plan at 9am, and then make it happen after standup? [19:29:39] ok [19:29:53] ottomata: I'll be gone at 10am your time, so 1h planning and checking, standup, then move :) [19:29:57] Cool [19:30:07] Thanks mate :) [19:32:35] By the way ottomata - Do you mind having a look at https://gerrit.wikimedia.org/r/#/c/424569/, see if you like it? [19:32:47] And now, I'm gone for tonight :) [19:33:16] joal: why not refinery-core? [19:33:35] ottomata: to prevent having spark into core [19:33:36] nm ignore! will comment on patch [19:33:46] goooodnight! [19:34:28] Tomorrow :) I ask because, since we need to restart all jobs for spark2, it'll be nice if we can move stuff at the same time :) [19:34:32] 10Analytics, 10Contributors-Analysis: Add raw sites table to Analytics Data Lake - https://phabricator.wikimedia.org/T191412#4118146 (10Neil_P._Quinn_WMF) >>! In T191412#4109433, @JAllemandou wrote: >Would `wmf_raw.mediawiki_project_namespace_map` saisfy the need ? This table is updated every month (snapshot p... [19:34:40] But if it's not the moment, let's not do it :) [19:35:17] 10Analytics, 10Contributors-Analysis: Add raw sites table to Analytics Data Lake - https://phabricator.wikimedia.org/T191412#4118165 (10Neil_P._Quinn_WMF) [19:38:56] (03CR) 10Ottomata: "I'm for the general idea, but I'm not sure about the 'refinery-spark' name." [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/424569 (https://phabricator.wikimedia.org/T188025) (owner: 10Joal) [19:40:19] (03CR) 10Ottomata: Move spark library code to refinery-spark package (031 comment) [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/424569 (https://phabricator.wikimedia.org/T188025) (owner: 10Joal) [19:40:39] (03CR) 10Ottomata: Move spark library code to refinery-spark package (031 comment) [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/424569 (https://phabricator.wikimedia.org/T188025) (owner: 10Joal) [19:43:44] 10Analytics, 10Contributors-Analysis: Make an Analytics Data Lake table to provide meta info about wikis - https://phabricator.wikimedia.org/T184576#3888657 (10Neil_P._Quinn_WMF) [20:25:55] ottomata: o/ [20:25:58] sorry just seen the ping [20:26:17] so the mirror maker alarm (if it has not changed) looks CRITICAL in icinga [20:26:27] with (null) as last value [20:26:39] buuut as you can see from the email it seems working fine when ran manually [20:26:47] so I guess that the !~ makes some trouble [20:26:51] but not sure where :( [20:28:41] Hi A-team! iOS team is going to implement eventlogging for the reading list feature. I'm thinking about using a different data schema from Android's (https://meta.wikimedia.org/wiki/Schema:MobileWikiAppReadingLists), and follow this guidelines https://wikitech.wikimedia.org/wiki/Analytics/Systems/EventLogging/Schema_Guidelines, but I'm wondering if the guidelines are still up to date. [20:39:53] (03CR) 10Nuria: [C: 031] Correct default memory of oozie launcher [analytics/refinery] - 10https://gerrit.wikimedia.org/r/425003 (owner: 10Joal) [20:40:58] chelsyx: they mostly are lemme look [20:41:27] i'd say don't worry about the dt field, that is added taken from capsule [20:41:29] now [20:41:35] but the rest, eyah [20:44:24] Thanks ottomata !