[09:16:56] <wikibugs>	 10Analytics, 10Analytics-Cluster, 06Operations, 13Patch-For-Review: Zookeeper heap usage patterns - https://phabricator.wikimedia.org/T157968#3024296 (10elukey) Moritz completed the restarts and the Heap usage pattern changed on all the nodes, so this is probably something to expect with the current settin...
[09:21:32] <moritzm>	 probably noone will notice at this time, but quick headsup that I'll install PHP security updates on bohrium/piwik in a minute
[09:23:43] <elukey>	 super
[09:24:29] <moritzm>	 done. elukey, are you able to make a quick check that all still works as expected?
[09:25:37] <elukey>	 moritzm: it seems working fine:)
[09:33:08] <moritzm>	 ok :-)
[09:38:01] <wikibugs>	 10Analytics-Tech-community-metrics: Updated data in mediawiki-identities DB not deployed onto wikimedia.biterg.io? - https://phabricator.wikimedia.org/T157898#3024337 (10Lcanasdiaz) @Aklapper I confirm this is broken right now. I'm appliying it manually today and talking with the guys to code the fix.
[10:01:58] <wikibugs>	 (03CR) 10Addshore: [C: 032] Remove minutely SPARQL script from CRON [analytics/wmde/scripts] - 10https://gerrit.wikimedia.org/r/336208 (https://phabricator.wikimedia.org/T146468) (owner: 10Addshore)
[10:02:03] <wikibugs>	 (03CR) 10Addshore: [C: 032] Remove minutely SPARQL script [analytics/wmde/scripts] - 10https://gerrit.wikimedia.org/r/336209 (https://phabricator.wikimedia.org/T146468) (owner: 10Addshore)
[10:02:06] <wikibugs>	 (03Merged) 10jenkins-bot: Remove minutely SPARQL script from CRON [analytics/wmde/scripts] - 10https://gerrit.wikimedia.org/r/336208 (https://phabricator.wikimedia.org/T146468) (owner: 10Addshore)
[10:02:12] <wikibugs>	 (03Merged) 10jenkins-bot: Remove minutely SPARQL script [analytics/wmde/scripts] - 10https://gerrit.wikimedia.org/r/336209 (https://phabricator.wikimedia.org/T146468) (owner: 10Addshore)
[11:00:54] <wikibugs>	 06Analytics-Kanban, 06Operations: Periodic 500s from piwik.wikimedia.org - https://phabricator.wikimedia.org/T154558#3024623 (10elukey) Just checked with Manuel if `thread_pool_size` was available for mysql 5.5 but it seems that it needs a proprietary extension to work.  I executed `SET GLOBAL max_connections=...
[11:43:04] <mforns>	 hey team!
[11:44:11] <joal>	 Hi mforns :)
[11:44:55] <joal>	 mforns: I feel bad - I didn't really provided help on the pagecounts thing :(
[11:45:21] <mforns>	 joal, ??? you gave most of the ideas!
[11:45:47] <joal>	 mforns: hm, I didn't really support though
[11:45:49] <joal>	 anyway :)
[11:46:06] <joal>	 mforns: how is it going now?
[11:46:22] <mforns>	 np, it took me a bit more time, but this way I won't forget, heheh
[11:46:40] <mforns>	 going well, I managed to read the output with an externat table
[11:47:01] <joal>	 Yay :)
[11:47:03] <mforns>	 also, found some parsing errors, there are some rows in the original pagecounts-raw data that are corrupt
[11:47:08] <joal>	 mforns: This outuput is CSV, right?
[11:47:14] <mforns>	 tsv, yes
[11:47:16] <joal>	 Arf mforns :(
[11:47:20] <mforns>	 compressed with snappy
[11:47:20] <joal>	 ok
[11:47:38] <mforns>	 but I don't thiks we can do anything, they are missing columns
[11:47:41] <joal>	 mforns: I think GZ compression would be better for this special case
[11:47:45] <mforns>	 anyway it's a small fraction
[11:47:48] <joal>	 k
[11:47:59] <mforns>	 joal, OK, I can change to gz
[11:48:17] <mforns>	 but the files are quite small
[11:48:18] <joal>	 mforns: Let's do it once the big rewriting is done :)
[11:48:42] <joal>	 mforns: It's not about data size, it;s more about format copnsistency for archived data
[11:49:03] <joal>	 mforns: I think in archive we try to use GZ for the data to be easily exportable on other platforms
[11:49:32] <mforns>	 I see, I read snappy was a faster codec (less compression), that's why I used it, given that files are small
[11:49:38] <mforns>	 but consistency makes sense
[11:50:24] <joal>	 mforns: and more than consistency, if we want to export data using rsync for instance, it'll be way easier to read on other systems if it's gz
[11:50:29] <mforns>	 joal, however, this is not going to be in archive, right? it's in the form of a table...
[11:50:39] <mforns>	 sure, makes sense
[11:51:00] <joal>	 mforns: I think we'll keep them in archive folder, no?
[11:51:19] <mforns>	 joal, OK makes sense as well
[11:51:24] <joal>	 mforns: We actually could have them in 2 places: archive in TSV.gz, core in parquet.snappy
[11:51:36] <joal>	 That's what we do with pageviews
[11:52:17] <mforns>	 joal, yes, but the files are so small, that the performance improvement in parquet+snappy won't be so high I guess
[11:52:29] <joal>	 mforns: true :)
[11:52:39] <joal>	 Maybe not needed :)
[11:52:40] <mforns>	 maybe it's not worth duplicating the data
[11:52:43] <mforns>	 ok
[11:52:51] <joal>	 At least for the projectcounts ones
[11:52:58] <mforns>	 let's see if the archive version + external table is enough
[11:53:02] <joal>	 If we get to pagecounts, it might be different
[11:53:15] <mforns>	 sure, the pagecounts will be wild
[12:09:41] * elukey lunch!
[12:18:58] <joal>	 Hi zareen 
[12:19:22] <zareen>	 hey joal
[12:19:32] <joal>	 zareen: The job I had launched failed :(
[12:19:43] <joal>	 zareen: I have launched a new one with more workers and smaller data
[12:20:04] <zareen>	 ahhh, do we know why?
[12:20:06] <joal>	 zareen: https://yarn.wikimedia.org/proxy/application_1486634611252_14350/
[12:20:34] <joal>	 zareen: too many partitions for too few workers
[12:21:17] <zareen>	 i see, thanks for launching another job
[12:22:18] <joal>	 zareen: no problem, it's my fault the previous one didn't work
[12:25:29] <joal>	 zareen: The job I pasted above is for the end of dec 2016
[12:25:42] <joal>	 zareen: I'll go with Jan 2017 after, then feb
[12:28:22] <zareen>	 joal: okay, so it will probably be at least another day or 2 before this table is ready with the latest data?
[12:28:30] <wikibugs>	 (03CR) 10Erik Zachte: [C: 032] Update banner with design consultation [analytics/wikistats] - 10https://gerrit.wikimedia.org/r/337452 (owner: 10Milimetric)
[12:28:43] <joal>	 zareen: I think you're right
[12:29:19] <wikibugs>	 06Analytics-Kanban: Hive code to count global unique devices per top domain (like *.wikipedia.org) - https://phabricator.wikimedia.org/T143928#3024816 (10JAllemandou) a:03JAllemandou
[12:29:28] <wikibugs>	 (03CR) 10Erik Zachte: [V: 032 C: 032] Update banner with design consultation [analytics/wikistats] - 10https://gerrit.wikimedia.org/r/337452 (owner: 10Milimetric)
[12:30:14] <zareen>	 hm, i'm tempted to re-run the monthly partitioned table from last week (with the new changes made) just in case this job doesn't run in the timeframe expected/fails
[12:30:42] <zareen>	 (as a separate table)
[12:32:19] <joal>	 zareen: I think this is not needed
[12:32:49] <zareen>	 joal: the job launched friday has 4 reducers, and the job launched today has 16. this might be a silly question, but what is the process if the number of reducers isn't set? (i've never specified number of reducers) does it just use all available resources?
[12:33:53] <joal>	 zareen: hive decides itself based on estimated data size
[12:35:09] <joal>	 zareen: while it's usually good for queries, for specific patterns like dynamic partitioning it might lead to unwanted results (many small files)
[12:35:39] <joal>	 So for our specific case, it's a tradeoff between volume of data treated at once and number of files at the end
[12:35:53] <wikibugs>	 (03CR) 10jenkins-bot: Update banner with design consultation [analytics/wikistats] - 10https://gerrit.wikimedia.org/r/337452 (owner: 10Milimetric)
[12:36:14] <zareen>	 joal: i see. okay, i'll monitor this job throughout the day. 
[12:36:37] <joal>	 zareen: it'll finish soon, I'll launch the Jan one after
[12:37:04] <zareen>	 joal: great, thanks for the help. 
[12:52:03] <elukey>	 joal: o/ - I added new alarms for Hadoop heap usage and there is a warning for an1055 - https://grafana.wikimedia.org/dashboard/db/analytics-hadoop?panelId=17&fullscreen
[12:52:07] <elukey>	 looks good :)
[12:52:42] <joal>	 elukey: looks like it works indeed :)
[12:52:50] <joal>	 elukey: that's great
[12:53:06] <joal>	 elukey: And with the NM patch, restart when alarm, no problemo :)
[13:39:50] <wikibugs>	 10Analytics-Cluster, 06Analytics-Kanban, 13Patch-For-Review, 15User-Elukey: Monitor Hadoop cluster running out of HEAP space with Icinga - https://phabricator.wikimedia.org/T88640#1016773 (10elukey)
[13:41:25] <wikibugs>	 10Analytics-Cluster, 06Analytics-Kanban, 06Operations, 13Patch-For-Review, 15User-Elukey: Zookeeper heap usage patterns - https://phabricator.wikimedia.org/T157968#3025004 (10elukey)
[14:03:37] <zareen>	 joal: sweet, dec 2016 job is complete :)
[14:05:50] <joal>	 zareen: launching Jan 2017
[14:06:16] <joal>	 zareen: As exepected, tradeoff - sorry for having been on the worng side for the first one
[14:06:26] <mforns>	 joal, qq: how can I mvn package refinery/source with scala 1.6?
[14:06:37] <zareen>	 joal: o/
[14:07:21] <joal>	 hm, mforns: you mean spark 1.6 right?
[14:07:30] <mforns>	 joal, sorry yes
[14:07:33] <joal>	 ok :)
[14:07:40] <joal>	 I am not sure I understand your question
[14:07:46] <mforns>	 change in the pom?
[14:07:49] <joal>	 Yes :)
[14:07:53] <mforns>	 aha
[14:08:29] <joal>	 mforns: I suggest for you to look at the Mediawiki History patch - I has this change in the pom IIRC
[14:08:38] <mforns>	 joal, OK thanks!
[14:08:43] <joal>	 np :)
[14:18:19] <mforns>	 joal, I don't manage to use it... should I use: import com.holdenkarau.sql.functions.input_file_name, instead of import org.apache.spark.sql.functions.input_file_name?
[14:18:38] <mforns>	 anyway that does not work either
[14:23:41] <mforns>	 joal, never mind, I was confused
[14:25:40] <joal>	 mforns: works now?
[14:25:44] <mforns>	 no...
[14:25:45] <joal>	 mforns: sorry I missed your ping
[14:25:47] <joal>	 Arf
[14:25:49] <mforns>	 np
[14:25:57] <joal>	 mforns: batcave?
[14:26:04] <mforns>	 sure joal 
[15:01:12] <milimetric>	 elukey: thought about piwik, for me I generally agree with what you say, this part is where there's grey area though: "a service needs to be supported properly or it should be dismissed"
[15:01:30] <milimetric>	 so normally that's true
[15:01:44] <milimetric>	 but ops specifically did not want to support piwik properly, and we brought it in anyway
[15:02:26] <milimetric>	 so I'm all for doing things the best way you see fit, and I agree that's using the mariadb module and letting the DBAs know about it
[15:03:12] <milimetric>	 but I also want to defend ops's right to reject supporting piwik, as they did initially
[15:03:28] <milimetric>	 otherwise there's this loophole where we keep sneaking in work for ops
[15:03:58] <wikibugs>	 (03PS1) 10Mforns: Add spark job to aggregate historical projectviews [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337593 (https://phabricator.wikimedia.org/T156388)
[15:05:45] <mforns>	 joal, meeting?
[15:06:25] <elukey>	 milimetric: morning :)
[15:06:39] <elukey>	 I discovered that we have the 'mysql' module, that might help
[15:06:58] <elukey>	 basically it handles for you all the things like custome /etc/mysql/conf.d erb template, etc..
[15:07:24] <elukey>	 milimetric: when was the last time that we discussed "ops specifically did not want to support piwik properly" ?
[15:07:37] <elukey>	 I doubt that the statement still holds
[15:07:50] <elukey>	 (especially since me and Andrew will take care of it :P)
[15:11:44] <joal>	 mforns, milimetric: joining now
[15:12:47] <milimetric>	 elukey: for some reason I didn't get your pings, the ops opinion was expressed in late 2015
[15:13:09] <milimetric>	 elukey: I totally agree that you joining changes the equation a lot, so that's why this is mostly up to you
[15:19:17] <elukey>	 milimetric: it really depends who are the users and what is their use case
[15:19:26] <elukey>	 it seems to me that the service has been running for a while
[15:19:37] <elukey>	 so we now should have a good idea about the use cases
[15:25:55] <wikibugs>	 10Analytics, 10DBA, 13Patch-For-Review: Set up auto-purging after 90 days {tick} - https://phabricator.wikimedia.org/T108850#3025412 (10jcrespo) a:05jcrespo>03None
[15:29:40] <wikibugs>	 10Analytics-Tech-community-metrics, 06Developer-Relations (Jan-Mar-2017): Merge detached SCM and SCR identities in korma DB if they have the same email address but not the same uuid - https://phabricator.wikimedia.org/T156283#3025416 (10Aklapper) > and then checking for items listed more than once. That manual...
[15:43:42] <wikibugs>	 (03PS6) 10Joal: Update sqoop script with labsdb specificity [analytics/refinery] - 10https://gerrit.wikimedia.org/r/334042 (https://phabricator.wikimedia.org/T155658)
[15:44:05] <wikibugs>	 (03PS19) 10Joal: Add mediawiki history spark jobs to refinery-job [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/325312 (https://phabricator.wikimedia.org/T141548)
[15:44:48] <joal>	 a-team, I'll be late in standup, need to spend some time with workers now - hopefully I'll be back before the end
[15:45:28] <milimetric>	 elukey: yes, use cases for piwik:
[15:45:32] <milimetric>	 * us on our dashboards
[15:45:43] <milimetric>	 * annual report, sites like 15.wikipedia.org, etc.
[15:45:47] <milimetric>	 * iOS app
[15:46:47] <milimetric>	 (also transparency report goes in that second bullet)
[15:47:20] <samtar>	 heyo all, not sure if you're the the right people to be asking, but I've been looking at getting a % of English Wikipedia administrators who haven't enabled 2FA (discussed from a security point of view at https://phabricator.wikimedia.org/T157500)
[15:47:23] <milimetric>	 I know more details about each one, and I guess except for the iOS app the rest of the use cases are totally fine with a lot of error
[15:47:56] <milimetric>	 hi samtar, where is 2FA enabling stored?  Do you know?  The db somewhere in user_options?
[15:48:38] <samtar>	 milimetric: I'm afraid I'm going to be useless here and say I have no idea - https://phabricator.wikimedia.org/T157500#3009105 sort of mentioned how we'd get at the data
[15:49:36] <milimetric>	 gotcha, ok, samtar, I'll take a look and see if I can run a quick query
[15:49:44] <milimetric>	 don't hang your hopes on me though :)
[15:50:03] <samtar>	 milimetric: it'd be great if you could, thank you :) if not, a shove in the right direction would be much appreciated
[15:50:16] <samtar>	 shame it's not an EventLogging schema
[15:50:47] <wikibugs>	 10Analytics, 10Analytics-EventLogging, 10DBA: Potentially decrease db1046's InnoDB buffer pool - https://phabricator.wikimedia.org/T125829#3025480 (10jcrespo) a:05jcrespo>03None
[15:52:19] <elukey>	 milimetric: now that I've increased max_connections, this seems to be the main issue https://github.com/piwik/piwik/issues/6398
[15:53:01] <milimetric>	 elukey: awesome, yeah that was happening before
[15:53:05] <milimetric>	 so you got rid of the 500s?!
[15:53:13] <milimetric>	 well, the _other_ 500s?
[15:53:22] <wikibugs>	 10Analytics: Render swagger spec docs as service endpoint - https://phabricator.wikimedia.org/T158066#3025501 (10Ottomata)
[15:53:35] <elukey>	 milimetric: I don't see the weird apache logs, at least it didn't show up during the last hours
[15:53:39] <elukey>	 this doesn't mean that it is gone :D
[15:53:41] <milimetric>	 samtar: do you happen to know what user groups you want me to check?  Here are the ones listed in english wiki's table:
[15:53:42] <wikibugs>	 10Analytics: Create EventStreams swagger spec docs endpoint - https://phabricator.wikimedia.org/T158066#3025513 (10Ottomata)
[15:53:43] <milimetric>	 https://www.irccloud.com/pastebin/2YczElst/
[15:54:01] <milimetric>	 elukey: yaaaay it's gone, you're awesome
[15:54:11] <wikibugs>	 10Analytics: Create EventStreams swagger spec docs endpoint - https://phabricator.wikimedia.org/T158066#3025501 (10Ottomata)
[15:54:17] <samtar>	 milimetric: `sysop` only please :)
[15:54:21] <milimetric>	 samtar: k
[15:54:38] <elukey>	 milimetric: but for example, now that I'd need to make the change permanent in the mysql config, with the current puppet configuration I'd need to put a file in /etc/mysql/conf.d/etc.. meanwhile a module would add that via erb template :P
[15:54:49] <elukey>	 ottomata: HIIIIiiiiIIIIiiii
[15:54:52] <elukey>	 how are you today?
[15:55:31] <ottomata>	 HIIIII
[15:55:36] <ottomata>	 ok, pretty phlegmy but ok!
[15:55:38] <ottomata>	 how are you?
[15:55:45] <milimetric>	 elukey: but there's a template for mysql config  there...
[15:56:02] <milimetric>	 piwik was taking mysql params from an ini file
[15:57:01] <elukey>	 milimetric: where is the mysql template? I might have missed it
[15:57:05] <elukey>	 do you mean in puppet?
[15:57:12] <milimetric>	 yeah
[15:58:48] <milimetric>	 elukey: I mean, wait, there should be... the research password is in there and everything
[16:01:35] <milimetric>	 elukey: that ini file is /etc/piwik/config.ini.php
[16:01:44] <milimetric>	 but you're right I'm not seeing a template for that?!
[16:01:51] <milimetric>	 this I definitely agree with you should be in puppet
[16:02:46] <milimetric>	 oooooh https://github.com/wikimedia/operations-puppet/blob/9b4bc170fba7d1623032d47a42ccf878ba382750/modules/role/manifests/piwik/server.pp#L6-L22
[16:05:19] <wikibugs>	 10Analytics-Cluster, 06Analytics-Kanban, 13Patch-For-Review, 15User-Elukey: Investigate if Node Managers can be restarted without impacting running containers - https://phabricator.wikimedia.org/T156932#3025571 (10Nuria) 05Open>03Resolved
[16:07:18] <wikibugs>	 06Analytics-Kanban, 13Patch-For-Review: CDH 5.10 upgrade - https://phabricator.wikimedia.org/T152714#3025576 (10Ottomata) Current plan: do this February Tues 28th.  I will send out announcement and schedule downtime.
[16:13:57] <wikibugs>	 06Analytics-Kanban: Check abnormal pageviews for XHamster - https://phabricator.wikimedia.org/T158071#3025609 (10Nuria)
[16:14:48] <elukey>	 milimetric: yep but there is no configuration file for mysql :D
[16:15:00] <elukey>	 say you need to set max_connections
[16:15:20] <milimetric>	 elukey: yeah, that's what the comment says, supposedly why it's impossible to have one with piwik
[16:15:32] <milimetric>	 so it pulls the config from pwstore somehow locally maybe?
[16:16:31] <elukey>	 milimetric: nono that part is mysql related, shouldn't be related to the piwik web installer
[16:16:45] <elukey>	 I am talking about files like /etc/mysql/conf.d/etc..
[16:17:06] <elukey>	 it is fine to have to bulk load the database etc..
[16:17:07] <milimetric>	 right, that'd be for the mysql for the box, you're right, we could stick config there
[16:17:37] <milimetric>	 it's dedicated to piwik anyway
[16:18:24] <milimetric>	 so I agree, instead of requiring just the package you would import the module and configure the threadpool, right?
[16:18:43] <elukey>	 yep exactly :)
[16:38:51] <ottomata>	 elukey:  should we review network acls real quick
[16:39:17] <samtar>	 milimetric: did you want me to assign that task to you btw?
[16:39:34] <milimetric>	 samtar: no, I'd only be doing a small part of it
[16:39:47] <samtar>	 Ah no worries ^^
[16:39:57] <milimetric>	 samtar: in a bunch of meetings for the next few hours, but trying to cobble the query together, should get it by end of day today
[16:40:05] <ateamslack>	 [fdans] is such a millennial, making everyone go into slack
[16:40:11] <milimetric>	 ahaha
[16:40:15] <samtar>	 No rush milimetric! :D
[16:48:23] <milimetric>	 nuria: when we moved retro it conflicts with Asaf's meeting
[16:48:26] <milimetric>	 which I would like to attend
[16:48:41] <nuria>	 milimetric: sorry, i do not have that meeting
[16:48:53] <milimetric>	 nuria: no, it's ok, just letting you know
[16:49:10] <milimetric>	 it's in 12 min., it sounds like a useful thing to have at least one of us at
[16:49:35] <nuria>	 what is meeting about?
[16:50:32] <milimetric>	 nuria:
[16:50:35] <milimetric>	 https://www.irccloud.com/pastebin/Evn1agKb/
[16:52:14] <nuria>	 milimetric: sorry it conflicts. Due to poststandup we always miss the first 10 mins of retro thus i though i would move it so we could have a full meeting
[16:53:05] <milimetric>	 true.  We could also just hard-end standup after 20 minutes on retro days
[16:53:20] <nuria>	 a-team: moved retro to tomorrow, looks like milimetric had an scheduling conflict
[16:53:29] <mforns>	 ok
[16:53:33] <milimetric>	 it has become a bit drawn-out lately, I actually was going to mention that at retro :)
[16:54:05] <nuria>	 milimetric: well, the teams we need to discuss do not magically disappear but maybe we can address that in adifferent way
[16:54:05] <ottomata>	 oook
[16:54:42] <joal>	 k
[16:55:09] <fdans>	 joal since we're not doing retro, do you have a few minutes a la grotte aux chauve-souris?
[16:55:11] <milimetric>	 sure, but we have to weigh that against really long standups like 1 hour.  That starts defeating the purpose of standup: quick short energizing meeting
[16:55:13] <joal>	 hey chasemp, are you around by any chance?
[16:55:28] <joal>	 sure fdans ! A la grotte aux chauves souris !
[16:56:12] <chasemp>	 joal: kind of :) just getting out of a meeting and pre-lunch
[16:57:40] <joal>	 chasemp: I'm after the process to ask you (or our beloved DBAs) to update the views with 2 new fields
[17:01:36] <chasemp>	 joal: I last ran it lasts week or so but I can do so again
[17:01:58] <joal>	 chasemp: Oh ?
[17:02:34] <chasemp>	 joal: https://phabricator.wikimedia.org/T153743#3009402
[17:03:01] <chasemp>	 looks like a few new things since then possibly
[17:03:30] <wikibugs>	 06Analytics-Kanban: Check abnormal pageviews for XHamster - https://phabricator.wikimedia.org/T158071#3025805 (10Nuria) a:03Nuria
[17:03:33] <joal>	 chasemp: the 2 fileds I'm talking about are  ar_content_model and ar_content_format in archive talbe
[17:03:41] <wikibugs>	 06Analytics-Kanban, 13Patch-For-Review: Add "Damn Small XSS Scanner" (DSXS) to list of known bots - https://phabricator.wikimedia.org/T157528#3025806 (10Nuria) 05Open>03Resolved
[17:04:10] <chasemp>	 joal: unf that same permission bug seems to have surfaced 'pymysql.err.OperationalError: (1142, "CREATE VIEW command denied to user 'maintainviews'@'localhost' for table 'abuse_filter_action'")'
[17:04:16] <chasemp>	 I'll have to ping the dba crew
[17:05:37] <wikibugs>	 06Analytics-Kanban, 10Analytics-Wikistats: Add "Interwicket" to the list of bots - https://phabricator.wikimedia.org/T154090#2900990 (10Nuria) a:03Nuria
[17:07:15] <wikibugs>	 06Analytics-Kanban: Check abnormal pageviews for XHamster - https://phabricator.wikimedia.org/T158071#3025815 (10MusikAnimal) A few things I found: * It seems the number of unique IPs that visited `/wiki/XHamster` is significantly less than articles that received around the same number of pageviews. * The top re...
[17:07:35] <wikibugs>	 06Analytics-Kanban, 10Analytics-Wikistats: Add "Interwicket" to the list of bots - https://phabricator.wikimedia.org/T154090#3025828 (10Nuria) anything "bot" should already be caught
[17:08:03] <wikibugs>	 06Analytics-Kanban, 06Operations, 10netops: Review ACLs for the Analytics VLAN - https://phabricator.wikimedia.org/T157435#3025831 (10Ottomata) > term udplog { + 1 > Remove IPs the term analytics-publicIP-v4: +1  > Review the IPs in term ssh Don't know anything about this, but also not sure why we have speci...
[17:09:55] <elukey>	 ottomata: I think that the kubernetes1003 reference in prelabsdb-mysql is an IP that  got recycled :(
[17:10:00] <ottomata>	 hm ok
[17:10:12] <ottomata>	 elukey:  these are all on the analytics vlan port?
[17:10:35] <elukey>	 yep
[17:15:22] <nuria>	 ottomata: I am getting cert errors downloading from archiva: 
[17:15:27] <nuria>	 https://www.irccloud.com/pastebin/y4u37ge3/
[17:16:01] <ottomata>	 bwaaah?
[17:17:42] <nuria>	 ottomata: yessir
[17:18:01] <nuria>	 https kaput?
[17:18:19] <ottomata>	 iinteresting, i get that too
[17:18:36] <ottomata>	 https should be resolved by the wildcard cert
[17:18:39] <ottomata>	 so that's weird
[17:19:03] <ottomata>	 nuria i gotta run to make a bus to get home real quick, will investigate more when I'm back
[17:19:11] <nuria>	 ottomata: np, no rush at all
[17:19:47] <ottomata>	 k back in a bit...
[17:57:19] * elukey afk! Talk with you tomorrow team!
[17:57:22] <elukey>	 byyeeee o/
[18:00:35] <joal>	 Bye elukey 
[18:05:41] <wikibugs>	 (03PS2) 10Mforns: Add spark job to aggregate historical projectviews [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337593 (https://phabricator.wikimedia.org/T156388)
[18:30:07] <ottomata>	 nuria:  did you upgrade java on your laptop recently?
[18:30:09] <ottomata>	 (I did)
[18:30:14] <ottomata>	 wonder if others who haven't get this error
[18:30:17] <nuria>	 no, no
[18:35:14] <travis-ci>	 wikimedia/mediawiki-extensions-EventLogging#634 (wmf/1.29.0-wmf.12 - 04e3fe4 : Translation updater bot): The build has errored.
[18:35:14] <travis-ci>	 Change view : https://github.com/wikimedia/mediawiki-extensions-EventLogging/compare/wmf/1.29.0-wmf.12
[18:35:14] <travis-ci>	 Build details : https://travis-ci.org/wikimedia/mediawiki-extensions-EventLogging/builds/201609654
[18:42:33] <wikibugs>	 (03CR) 10Joal: "Some comments inline :)" (0310 comments) [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337593 (https://phabricator.wikimedia.org/T156388) (owner: 10Mforns)
[18:42:43] <mforns>	 thanks :]
[18:42:49] <joal>	 np mforns :)
[18:43:02] <joal>	 I love the power of the mapPartition trick :)
[18:43:33] <ottomata>	 nuria:  pretty sure it is a problem with something on our laptops
[18:43:42] <ottomata>	 refinery/source builds fine on stat1002
[18:49:48] <mforns>	 joal, you comment that the files are stored in monthly folders, but in the end I went for no partitions in the hive table, so all files will be in the root folder, you see a problem in that?
[18:50:08] <joal>	 mforns: absolutely not :)
[18:50:25] <mforns>	 ok
[18:50:37] <joal>	 mforns: something we didn't consider that could be interesting would be to sort the output
[18:51:00] <mforns>	 joal, yes, makes sense, I struggled a bit to vet the data, it would have helped. Will do
[18:51:04] <joal>	 Since it is TSV (not parquet), sorted will be easier to read for users
[18:51:12] <mforns>	 totally
[18:51:17] <joal>	 mforns: last thought (sorry, forgot to mention in the CR)
[18:51:24] <mforns>	 no no go ahear
[18:51:28] <mforns>	 *ahead
[18:51:57] <joal>	 I think since those files are ready-for-export (in some ways), outpuing a single file is better
[18:52:19] <joal>	 I'd still use the number of partitions to reduce by more efficiently, but then would coalesce to 1
[18:53:26] <joal>	 But, in that case, since gz is not splittable, it means hadoop cannot parallelise work... hmmmm
[18:53:52] <joal>	 I think I'd actually prefer a partition by year with single files in each
[18:53:57] <joal>	 For the reasosn above
[18:54:02] <joal>	 makes sense mforns |
[18:54:03] <joal>	 ?
[18:55:31] <ottomata>	 nuria:  i'm taking it back, i think there might be something not right with the cert
[18:58:53] <wikibugs>	 10Analytics, 10MediaWiki-extensions-WikimediaEvents, 10The-Wikipedia-Library, 10Wikimedia-General-or-Unknown, 13Patch-For-Review: Implement Schema:ExternalLinksChange - https://phabricator.wikimedia.org/T115119#3026457 (10Samwalton9)
[18:59:58] <mforns>	 joal, a year of projectcounts-raw is around 50MB
[19:00:32] <joal>	 mforns: is it a good file-size, or to big even?
[19:00:51] <mforns>	 joal, I think it's good
[19:01:33] <joal>	 mforns: Do you see my point about how to access / sort etc?
[19:01:48] <mforns>	 but then the writing of the yearly files will be done "by hand", because I don't think there's a way of defining hive partitions in a dataframe
[19:02:21] <joal>	 mforns: I think best could possibly be to have 1 gz file per year, with everything in a single folder for hive to parse (or with parttions, I don't miond)
[19:02:32] <mforns>	 so something like: for year in years: write("/year=2007/" + outputPath)
[19:02:38] <joal>	 mforns: There definitely are
[19:02:59] <joal>	 mforns: the problem is more about using CSV formatter with partitions
[19:03:25] <joal>	 mforns: http://stackoverflow.com/questions/37509932/write-spark-dataframe-as-csv-with-partitions
[19:03:42] <mforns>	 joal, but if gzip is not splittable, how are we having multiple gzipped files in a folder? will hive be able to read them?
[19:04:07] <joal>	 mforns: hive has no problem reading multiple files
[19:04:28] <joal>	 mforns: issue with non-splittable files is that a single mapper needs to read them (instead of potentially more than one)
[19:04:44] <mforns>	 Ah! I see
[19:04:57] <joal>	 But with 50mb file size, we're very ok :)
[19:05:19] <mforns>	 ok
[19:12:12] <wikibugs>	 06Analytics-Kanban: Document the difference in aggregate data on wikistats and wikistats 2.0 - https://phabricator.wikimedia.org/T150963#3026551 (10Elitre) I also checked after a week and provided some advice, our intervention during this Phase 1 is not anticipated.
[19:12:30] <ottomata>	 nuria:  i think i have a fix
[19:12:31] <ottomata>	 can you try?
[19:18:10] <ottomata>	 nuria:  https://wikitech.wikimedia.org/wiki/Archiva#Using_new_Let.27s_Encrypt_SSL_certs
[19:34:32] <chasemp>	 joal: see if your views are there now?
[19:34:42] <chasemp>	 there is some auth bug that got in the way but in theory we overcame
[19:35:07] <wikibugs>	 10Analytics, 10Wikimedia-Stream: Update EventBus RCFeed config to use newly refactored settings - https://phabricator.wikimedia.org/T158106#3026676 (10Ottomata)
[19:35:15] <joal>	 chasemp: specific wiki?
[19:35:37] <chasemp>	 it should be fine everywhere the wikidb exists and the field
[19:35:43] <chasemp>	 it was a mass update of existing things
[19:35:43] <joal>	 chasemp: It's not actually views, it's specific fields of a an existing view
[19:35:47] <chasemp>	 ah
[19:35:54] <chasemp>	 maybe I misunderstood
[19:35:57] <joal>	 And, not changed
[19:36:05] <chasemp>	 is this a field that does not exist in a view that is created?
[19:36:07] <joal>	 I'm sorry if I've been unclear
[19:36:16] <joal>	 correct chasemp 
[19:36:21] <chasemp>	 no worries, it would been a quick circle back if not for the bug etc
[19:36:39] <joal>	 mwarf
[19:37:08] <chasemp>	 ah, so the process is largely I think the same for adding fields to a view (create a task, we put up a proposed change to the views yaml definition file, and bug one of the security folks to ok it)
[19:37:18] <nuria>	 ottomata: trying
[19:37:24] <chasemp>	 I can't add fields to the view, or at least don't feel empowered to without that
[19:37:27] <chasemp>	 or more to the point
[19:37:29] <joal>	 chasemp: details: in revision table, there are rev_content_model and rev_content_format, but in archive, no ar_content_format nor ar_content_model
[19:37:38] <chasemp>	 hm
[19:38:22] <joal>	 chasemp: I create a new task and flag it with labs-infra and DBA ?
[19:38:41] <nuria>	 ottomata: you were totally right, i upgraded to java 8, but was a long time ago, i think it is been a while since i needed new deps
[19:38:58] <chasemp>	 we can do that dance together, yeah, make a task, and upload a proposed changeset to /etc/maintain-views.yaml 
[19:39:07] <chasemp>	 and we'll try to wrangle whoever can say it's ok to expose
[19:39:09] <ottomata>	 nuria:  i don't think it was java 8
[19:39:16] <ottomata>	 i think it was the lets encrypt ca chnage
[19:39:17] <chasemp>	 it's a pita but it's mostly for good reasons I think
[19:39:30] <chasemp>	 and largely as it's been mostly unmanaged I think so can only get better? :)
[19:39:41] <joal>	 huhu chasemp :)
[19:40:04] <joal>	 the /etc/maintain-views.yaml file is in puppet?
[19:40:32] <chasemp>	 'tis
[19:40:32] <chasemp>	 modules/role/templates/labs/db/views/maintain-views.yaml
[19:40:58] <chasemp>	 here is whta I see for the view now
[19:41:00] <chasemp>	 select rev_id, rev_page, if(rev_deleted&1,null,rev_text_id) as rev_text_id, if(rev_deleted&2,n$
[19:41:00] <chasemp>	       as rev_comment, if(rev_deleted&4,null,rev_user) as rev_user, if(rev_deleted&4,null,rev_user_te$
[19:41:01] <chasemp>	       rev_timestamp, rev_minor_edit, rev_deleted, if(rev_deleted&1,null,rev_len) as rev_len, rev_par$
[19:41:02] <chasemp>	       if(rev_deleted&1,null,rev_sha1) as rev_sha1, rev_content_model, rev_content_format
[19:41:11] <joal>	 chasemp: awesome - I'm gonna leave for tonight but will submit a patch later on
[19:41:12] <chasemp>	 which is not easy to reason about for me honestly
[19:41:14] <chasemp>	 ok
[19:41:22] <joal>	 thanks again chasemp !
[19:41:27] <joal>	 a-team, gone for tonight :)
[19:42:11] <ottomata>	 laters!
[19:47:29] <nuria>	 ottomata: yours truly had some ahem... mix of java versions
[19:47:36] <nuria>	 ottomata: all good
[19:47:38] <nuria>	 now
[19:48:50] <wikibugs>	 (03PS1) 10Nuria: Add "Interwicket" to the list of bots [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337632 (https://phabricator.wikimedia.org/T154090)
[19:49:44] <wikibugs>	 10Analytics-Dashiki, 06Analytics-Kanban, 13Patch-For-Review: Add Map component to dashiki layout - https://phabricator.wikimedia.org/T153921#3026716 (10Nuria) 05Open>03Resolved
[19:50:09] <wikibugs>	 06Analytics-Kanban, 10Analytics-Wikistats: Visual Language for http://stats.wikimedia.org replacement - https://phabricator.wikimedia.org/T152033#3026719 (10Nuria)
[19:50:11] <wikibugs>	 06Analytics-Kanban: Involve the community in Wikistats 2.0 design. Stage 1. - https://phabricator.wikimedia.org/T156287#3026718 (10Nuria) 05Open>03Resolved
[19:50:47] <ottomata>	 great
[20:08:35] <wikibugs>	 06Analytics-Kanban: Document the difference in aggregate data on wikistats and wikistats 2.0 - https://phabricator.wikimedia.org/T150963#3026824 (10Milimetric) Thanks Elitre.  For Phase 2, we added the planned March 3rd - March 10th consultation on this page: https://meta.wikimedia.org/wiki/Community_Engagement/...
[20:10:26] <nuria>	 ottomata: for cluster upgrade ... wouldn't it be better middle of the month so when it comes back to live it doesn't have to face 1st thing the major amount of work that are monthly jobs? 
[20:10:48] <wikibugs>	 10Analytics, 10MediaWiki-extensions-WikimediaEvents, 10The-Wikipedia-Library, 10Wikimedia-General-or-Unknown, 13Patch-For-Review: Implement Schema:ExternalLinksChange - https://phabricator.wikimedia.org/T115119#3026829 (10Milimetric) @Samtar: that delay is most likely due to event logging replication cat...
[20:11:45] <samtar>	 milimetric: about?
[20:12:11] <ottomata>	 i geuss that is the next day..
[20:12:15] <ottomata>	 but nuria no good time other than that
[20:12:20] <ottomata>	 unless we wait longer
[20:12:29] <samtar>	 (just to discuss T115119 if you have a mo)
[20:12:29] <stashbot>	 T115119: Implement Schema:ExternalLinksChange - https://phabricator.wikimedia.org/T115119
[20:12:33] <nuria>	 ottomata: k, your call
[20:13:10] <nuria>	 samtar: sure
[20:14:33] <nuria>	 samtar: do you have a question?
[20:14:48] <samtar>	 or nuria ^^ - so milimetric has said that a delay of an hour or so is to be expected on stat1003, now this might just be my lack of understanding (and I would *not* be surprised if that's all it is!) but aren't EventLogging events logged straight to stat1003?
[20:15:00] <nuria>	 samtar: no, they are not
[20:15:05] <nuria>	 samtar: that is a DB replica
[20:15:18] <milimetric>	 hm, why am I missing 1/2 my pings all of a sudden
[20:15:22] <milimetric>	 sorry nuria, I'm around
[20:15:53] <milimetric>	 yeah, samtar, it's a replica with batched custom replication
[20:15:53] <samtar>	 nuria: well then there you go :) so for example I'm looking at ExternalLinksChange - they come from production to stat1003?
[20:16:03] <nuria>	 samtar: for all events
[20:16:13] <samtar>	 and it's that replication which is the delay?
[20:16:14] <ottomata>	 (for correctness, stat1003 is not a db replica :) )
[20:16:15] <nuria>	 samtar: data is logged to prod (master) and replicated
[20:16:30] <nuria>	 ottomata: sorry, not a replica, but not-prod either
[20:16:36] <ottomata>	 there is no db on stat1003
[20:16:38] <milimetric>	 right, analytics-store is the replica
[20:16:46] <milimetric>	 which can be accessed from stat1003
[20:16:49] <ottomata>	 :)
[20:16:54] <nuria>	 samtar: delay depends on how busy dbs are
[20:17:13] <nuria>	 samtar: if some maintenace is going on, delays might be big 
[20:17:17] <milimetric>	 heh, though technically analytics-store is just a domain name for I don't know what actual server
[20:17:35] <samtar>	 Okay, because the delay is one thing, but every now and then it just plainly misses some events - this could well be down to the logging code itself
[20:17:51] <samtar>	 but to summarise, a delay of an hour is normal?
[20:18:10] <samtar>	 or is that a little high?
[20:18:27] <wikibugs>	 (03CR) 10Milimetric: "I commented on a small preference for the sqooping function, take a look and self-merge after that whichever way you decide (not a strong " (031 comment) [analytics/refinery] - 10https://gerrit.wikimedia.org/r/334042 (https://phabricator.wikimedia.org/T155658) (owner: 10Joal)
[20:18:42] <samtar>	 (I realise that's probably a `how long is a piece of string` style question :P)
[20:19:32] <nuria>	 samtar: delay would not make it miss events, that is , as you said, related to your client side code 
[20:20:04] <nuria>	 samtar: makes sense?
[20:20:22] <samtar>	 nuria: yes definitely, thank you for the clarification :) 
[20:22:00] <nuria>	 samtar: but i would test for events on beta, rather than prod
[20:23:13] <milimetric>	 samtar: the missing of events on that schema is due to the implementation.  It seems to be a very tricky issue that Lego couldn't figure out, related to an interaction with another extension
[20:23:37] <zareen>	 joal: looks like January 2017 job is done! :) https://yarn.wikimedia.org/cluster/app/application_1486634611252_14631 could you please launch Feb 2017 job when you get a chance? 
[20:24:01] <milimetric>	 but in general, if you do event X, Y, and Z, in that order, and you only see event X and Z in the database after a while, then it's 99% likely Y never got sent
[20:24:19] <samtar>	 milimetric: interesting.. that seems to be what we're getting
[20:24:32] <milimetric>	 samtar: check out Lego's possible explanation on that task
[20:24:36] <samtar>	 appreciate it's not analytics' issue though!
[20:24:58] <milimetric>	 I don't know enough about mediawiki to help, but happy to brain-bounce if you know how things work and just need someone to talk it over
[20:25:05] <milimetric>	 I've been rooting for that issue to be resolved for like a year
[20:32:12] <wikibugs>	 (03PS1) 10Ottomata: Add --partition-type option to refinery-drop-hourly-partitions script [analytics/refinery] - 10https://gerrit.wikimedia.org/r/337638 (https://phabricator.wikimedia.org/T146915)
[20:32:56] <wikibugs>	 (03CR) 10Ottomata: [V: 032 C: 032] Add --partition-type option to refinery-drop-hourly-partitions script [analytics/refinery] - 10https://gerrit.wikimedia.org/r/337638 (https://phabricator.wikimedia.org/T146915) (owner: 10Ottomata)
[20:33:34] <milimetric>	 ottomata: we should add "The WMF Analytics team code reviews jobs that publish data here" to https://analytics.wikimedia.org/datasets/README
[20:34:47] <ottomata>	 milimetric:  send me full paste of whatever you want in there, and I will change it!
[20:35:55] <milimetric>	 https://www.irccloud.com/pastebin/Zy4aQSsj/
[20:35:59] <milimetric>	 ottomata: ^
[20:36:01] <milimetric>	 thanks
[20:48:32] <wikibugs>	 (03PS1) 10Milimetric: [WIP] DO NOT MERGE [analytics/dashiki] - 10https://gerrit.wikimedia.org/r/337642 (https://phabricator.wikimedia.org/T125854)
[20:53:04] <wikibugs>	 10Analytics-Cluster, 06Analytics-Kanban, 06Operations: Move cloudera packages to a separate archive section - https://phabricator.wikimedia.org/T155726#3027062 (10Ottomata) a:03Ottomata
[20:54:20] <milimetric>	 ottomata: :( we forgot that reportupdater does its own syncing now
[20:54:30] <ottomata>	 milimetric:  ?
[20:54:40] <milimetric>	 it has an rsync_to: thorium::/srv/limn-public-data
[20:54:52] <milimetric>	 so it's going to come on top of the rsync scripts you made
[20:55:32] <ashgrigas>	 nuria milimetric fdans mforns emailed you first draft for dashboard visd
[20:55:36] <ashgrigas>	 please send feedback
[20:55:41] <nuria>	 ashgrigas: k
[20:55:44] <mforns>	 ashgrigas, will do! thanks :]
[20:55:51] <ottomata>	 hmm, ok, well, we can disable that later, right?  if we make it write out, or sync to published-datasets
[20:55:52] <milimetric>	 that was fast, thanks ash
[20:55:53] <ottomata>	 that should be fine
[20:55:54] <ottomata>	 right?
[20:56:02] <ottomata>	 or milimetric if it is easiest, it can just do a local rsync_to:
[20:56:12] <milimetric>	 right /srv/published-datasets
[20:56:13] <milimetric>	 hm
[20:56:16] <ottomata>	 rsync_to /a/published-datasets/ ... should be ok
[20:56:17] <ottomata>	 yeah
[20:56:21] <ottomata>	 (it is /a on stat1002
[20:56:25] <ottomata>	 unfortunetly
[20:56:30] <milimetric>	 right, i'm on 1003
[20:56:32] <ottomata>	 oh ok
[20:56:33] <ottomata>	 then yeah
[20:56:39] <milimetric>	 (that's almost all the RU jobs)
[20:57:18] <milimetric>	 yeah that seems fine, though it adds yet more delay on the reports getting out
[20:57:23] <milimetric>	 'cause they're rsync-ed twice now
[21:02:22] <milimetric>	 ottomata: can I rsync it to thorium::/srv/analytics.wikimedia.org/datasets/periodic/
[21:03:09] <ottomata>	 hmm, not really milimetric beacuse of the rsync --delete stuff
[21:03:21] <ottomata>	 hmm lemme think
[21:03:23] <milimetric>	 ok
[21:03:24] <ottomata>	 is that true?
[21:03:38] <milimetric>	 yeah, it won't exist on 1002 or 1003 so it'll delete it, you're right
[21:03:48] <milimetric>	 I think we've created a monster
[21:03:56] <ottomata>	 yeah no, that won't work
[21:04:01] <ottomata>	 haha
[21:04:08] <ottomata>	 i mean, it can go to a different place
[21:04:13] <ottomata>	 analytics.wm.org/reports
[21:04:13] <ottomata>	 ?
[21:04:40] <ottomata>	 milimetric:  why does it have to rsync at all now though?
[21:04:45] <ottomata>	 can't it just write out to /srv/published-datasets locally
[21:04:46] <ottomata>	 ?
[21:05:15] <milimetric>	 it's just the way RU works, it writes to $base/reportupdater/output/
[21:07:12] <milimetric>	 ottomata: can we make another directory on thorium under /srv/published-datasets-rsynced?
[21:08:42] <ottomata>	 hm
[21:09:17] <ottomata>	 milimetric:  wonder if ln -s $base/reportupdater/output /srv/published-datasets/reports would work
[21:10:22] <milimetric>	 yeah, that's kind of how it works now, limn-public-data is a link to RU/output
[21:10:31] <milimetric>	 but we'd have to remove rsyncing from RU's puppet module
[21:10:47] <milimetric>	 and I forget why we added it in the first place
[21:11:21] <milimetric>	 also, small thing, I was thinking of calling it "periodic" instead of "reports" because it's more descriptive and I want people to use reportupdater for periodic jobs
[21:11:29] <milimetric>	 (so we can review their code)
[21:12:48] <madhuvishy>	 ottomata: Hiii you have some commits unmerged on puppet-master, can i merge them? :)
[21:15:54] <ottomata>	 oop!
[21:16:13] <ottomata>	 yes madhuvishy thank you
[21:16:16] <ottomata>	 i thought i merged those!
[21:16:17] <madhuvishy>	 cool
[21:16:35] <madhuvishy>	 merging ;)
[21:19:11] <wikibugs>	 06Analytics-Kanban, 06Discovery-Analysis, 07Browser-Support-Apple-Safari: Visits/searches from Safari 10 location bar search suggestions - https://phabricator.wikimedia.org/T157796#3027160 (10debt) p:05Triage>03Normal
[21:23:22] <wikibugs>	 (03PS3) 10Mforns: Add spark job to aggregate historical projectviews [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337593 (https://phabricator.wikimedia.org/T156388)
[21:23:39] <wikibugs>	 (03CR) 10Mforns: Add spark job to aggregate historical projectviews (0310 comments) [analytics/refinery/source] - 10https://gerrit.wikimedia.org/r/337593 (https://phabricator.wikimedia.org/T156388) (owner: 10Mforns)
[21:23:57] <ottomata>	 ok
[21:24:11] <ottomata>	 milimetric:  let's try the symlink thing then
[21:24:23] <wikibugs>	 06Analytics-Kanban, 10Analytics-Wikistats, 13Patch-For-Review: Add "Interwicket" to the list of bots - https://phabricator.wikimedia.org/T154090#3027193 (10Nemo_bis) >>! In T154090#3026709, @gerritbot wrote: > Change 337632 had a related patch set uploaded (by Nuria): > Add "Interwicket" to the list of bots...
[21:24:34] <milimetric>	 ottomata: https://gerrit.wikimedia.org/r/#/c/337672/ take a look and let me know what you think
[21:24:44] <milimetric>	 and also what the best way to do the ln -s is
[21:24:48] <milimetric>	 (in puppet)
[21:25:29] <milimetric>	 man I ate one of the new beyond meat burgers, and my body is seriously confused
[21:25:57] <ottomata>	 haha
[21:25:58] <ottomata>	 what is that?
[21:26:55] <ottomata>	 milimetric:  you know how to declarea  file in puppet?
[21:27:00] <ottomata>	 same way, except you want to add
[21:27:02] <ottomata>	 ensure => 'link
[21:27:03] <ottomata>	 '
[21:27:04] <ottomata>	 and
[21:27:05] <wikibugs>	 06Analytics-Kanban, 13Patch-For-Review: Clean up datasets.wikimedia.org - https://phabricator.wikimedia.org/T125854#3027202 (10Milimetric) Those last two patches should hopefully be all the code changes we need.  Now we need to:  1. fix and merge the puppet one 2. test that dashboards work with it 3. merge the...
[21:27:14] <ottomata>	 target => '/path/to/source/file'
[21:27:16] <ottomata>	 so 
[21:27:40] <milimetric>	 k, no I know that way, just making sure it's correct in that context and you don't think we should factor it out into reportupdater or anything
[21:28:10] <milimetric>	 (I'm talking about the two TODO lines in that puppet patch)
[21:28:34] <ottomata>	 oh ok
[21:28:35] <ottomata>	 hm
[21:28:39] <ottomata>	 no i think there is good
[21:28:41] <ottomata>	 hm
[21:28:43] <mforns>	 bye a-team, see you tomorrow!
[21:28:48] <ottomata>	 might be nice to not hardcode the published-datasets path though
[21:29:33] <milimetric>	 where are you defining it in the first place, for the rsync script?
[21:29:48] <milimetric>	 the burger is this thing: https://www.youtube.com/watch?v=4-PT0VDKno0
[21:30:04] <wikibugs>	 (03CR) 10Nuria: "@EBernhardson, if you clear merge conflicts we can probably merge this one. Thank you" [analytics/refinery] - 10https://gerrit.wikimedia.org/r/335158 (owner: 10EBernhardson)
[21:30:07] <ottomata>	 milimetric:  mind if iI amend your patch?
[21:30:13] <milimetric>	 not at all, go for it
[21:30:51] <ottomata>	 milimetric:  so beyond meet == good?
[21:31:46] <milimetric>	 it's not meat, but it tricks Tiger Lily and if you take a quick bite you might not notice.  Definitely light years ahead of tofu and stuff like that
[21:32:40] <milimetric>	 haha, this dude in the video says it has no odor, it definitely does, so don't trust whatever he says on taste
[21:39:57] <wikibugs>	 (03PS5) 10EBernhardson: Adjust drop hourly script to handle mediawiki log partitions [analytics/refinery] - 10https://gerrit.wikimedia.org/r/335158
[21:40:59] <wikibugs>	 (03PS6) 10EBernhardson: Adjust drop hourly script to handle mediawiki log partitions [analytics/refinery] - 10https://gerrit.wikimedia.org/r/335158
[21:41:47] <ottomata>	 ebernhardson: doesn't camus create directories with hourly/ ...
[21:41:47] <ottomata>	 ?
[21:42:08] <ebernhardson>	 ottomata: yes, but its already in the table spec
[21:42:18] <ottomata>	 ?
[21:42:35] <ottomata>	 oh hourly is in your table exteranal LOCATION?
[21:42:58] <ebernhardson>	 ottomata: yea
[21:43:00] <ottomata>	 i think we should probably rename the 'raw' partition type to camus
[21:43:09] <ottomata>	 and drop the 'hourly' part of partition_globs in the script
[21:43:18] <ottomata>	 afaik there isn't anybody currently using partition type raw
[21:43:21] <ottomata>	 at least its not puppetized.. :)
[21:43:31] <ottomata>	 and just rely on --table-location flag
[21:43:31] <ottomata>	 always
[21:43:36] <ottomata>	 --location
[21:43:37] <ebernhardson>	 hmm, thats reasonable if nothing is auto-detecting
[21:44:41] <ottomata>	 milimetric:  https://gerrit.wikimedia.org/r/#/c/337672/
[21:45:01] <milimetric>	 yep, I checked it out, thanks ottomata, commented
[21:45:07] <milimetric>	 basically +1 but let's wait till tomorrow
[21:45:18] <milimetric>	 we can do it tomorrow morning
[21:45:43] <ottomata>	 k
[21:48:30] <wikibugs>	 (03PS7) 10EBernhardson: Adjust drop hourly script to handle mediawiki log partitions [analytics/refinery] - 10https://gerrit.wikimedia.org/r/335158
[21:51:04] <ebernhardson>	 in that case though, it seems we could almost skip changing the script and specify location without the 'hourly' part
[21:51:40] <wikibugs>	 (03CR) 10Ottomata: [V: 032 C: 032] Adjust drop hourly script to handle mediawiki log partitions [analytics/refinery] - 10https://gerrit.wikimedia.org/r/335158 (owner: 10EBernhardson)
[21:51:46] <ottomata>	 thanks ebernhardson
[21:56:04] <ebernhardson>	 ottomata: actually i just grabbed the latest copy of puppet, and it has a new refinery-drop-wdqs-extract-partitions that doesn't specify a partition type, so it's getting raw currently
[21:57:18] <ebernhardson>	 oh nvm i can't read, it's using hive partition type
[21:59:03] <ottomata>	 :)
[21:59:06] <ottomata>	 yeah just short options
[21:59:09] <ottomata>	 i just committed that today
[22:01:11] <wikibugs>	 10Analytics-Cluster, 06Analytics-Kanban, 06Operations, 13Patch-For-Review: Move cloudera packages to a separate archive section - https://phabricator.wikimedia.org/T155726#3027384 (10Ottomata) TODO after CDH upgrade, remove old cloudera/thirdparty updates.
[22:01:31] <joal>	 Gone for now a-team
[22:01:36] <joal>	 see you tomorrow
[22:01:53] <milimetric>	 good night^morning joal 
[22:41:18] <wikibugs>	 10Analytics, 06Research-and-Data: geowiki data for Global Innovation Index - https://phabricator.wikimedia.org/T131889#3027569 (10leila) @Milimetric I ran the following   ``` select country, sum(edits) from staging.erosen_geocode_country_edits where ts like '2016-%' group by country order by sum(edits) desc; `...
[23:32:28] <wikibugs>	 06Analytics-Kanban, 13Patch-For-Review: Add "Damn Small XSS Scanner" (DSXS) to list of known bots - https://phabricator.wikimedia.org/T157528#3027726 (10Tbayer) Thanks for the quick merge! To document the effect on total pageviews for later reference, here is a plot of the daily percentage (for the timespan wh...