[08:22:45] <joal>	 heya elukey o/
[08:22:57] <elukey>	 hola!
[08:23:04] <joal>	 wassup?
[08:23:57] <elukey>	 trying to make pivot working, need to work on puppet because there are some issues :(
[08:24:02] <elukey>	 the rest is good
[08:24:06] <elukey>	 )
[08:24:06] <joal>	 great :)
[08:24:28] <joal>	 anything Ican help for decommissioning ol d aqs'?
[08:25:13] <elukey>	 joal: all good from your side?
[08:25:33] <elukey>	 if you could just stop the oozie machinery to update the old cluster it would be enough
[08:25:46] <joal>	 I have looked at graphs regularly, and spotted nothing
[08:25:47] <elukey>	 after that it is only a matter of merging
[08:25:52] <joal>	 elukey: ok
[08:26:13] <joal>	 elukey: Stopping old aqs loading is reasonably easy (easier than starting it at least ;)
[08:26:30] <elukey>	 joal: with "from your side" I meant "how's going?" :)
[08:26:39] <joal>	 Ah ;)
[08:27:48] <joal>	 Well, looking in hive if the ratio views / distinct UserAgent doesn't give too many false positive, and continuing to move on scala for edit history (this one is my never ending one ...)
[08:28:45] <elukey>	 :D
[08:49:12] <grrrit-wm1>	 (PS1) Elukey: Updated scap configuration [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315050 (https://phabricator.wikimedia.org/T138262)
[08:49:39] <grrrit-wm1>	 (CR) Elukey: [C: 2 V: 2] Updated scap configuration [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315050 (https://phabricator.wikimedia.org/T138262) (owner: Elukey)
[09:04:24] <joal_>	 elukey: ping?
[09:05:20] <elukey>	 pong
[09:06:13] <joal_>	 elukey: you probably have missed my previsous mesage :)
[09:06:25] <joal_>	 elukey: Do you mind if I deploy refinery now ?
[09:09:32] <elukey>	 ah yes I didn't see it :(
[09:09:34] <elukey>	 not at all
[09:09:38] <joal_>	 elukey: no prob :)
[09:09:41] <joal_>	 ok
[09:09:45] <joal_>	 Deploy now then !
[09:09:47] <elukey>	 whenever you have time I'd need some help with Pivot's first deploy
[09:10:13] <joal_>	 elukey: sure ! I'm no javascript nor web-server expert, but whatever I can help with :)
[09:10:27] <elukey>	 it is more scap first time deployment and permissions
[09:10:29] <elukey>	 :)
[09:10:45] <joal_>	 hm, I'm no scap expert neither :-P
[09:10:47] <joal_>	 huhu
[09:11:03] <joal_>	 I can however do some rubberducking :)
[09:16:03] <joal_>	 !log Deploy refinery
[09:48:34] <mobrovac>	 elukey: i can help
[09:48:45] * mobrovac last famous words
[09:49:52] <elukey>	 mobrovac: I am pretty sure it is a PEBKAC as always :D
[09:50:01] <mobrovac>	 haha
[09:51:43] <elukey>	 so I have on tin /srv/deploymnet/analytics/pivot/deploy and both scap deploy on it and scap deploy-local on stat1001 (the target) are failing.. the former due to perms even opening the log files
[09:52:23] <elukey>	 so I am surely missing something because I have little experience with new repos in scap
[09:52:50] <mobrovac>	 k, lemme take a look on tin
[09:57:38] <mobrovac>	 elukey: in /srv/deployment/analytics/pivot/deploy, you need to chmod g+w scap
[09:57:56] <mobrovac>	 scap can't create its log dir under your user so it fails flat out
[10:00:23] <elukey>	 mobrovac: yep I noticed that but I was wondering if the problem is "normal" or if my perms were not right due to some misconfiguration from my side
[10:00:33] <elukey>	 for example, after the chmod that you suggested I get "error: insufficient permission for adding an object to repository database .git/objects"
[10:00:51] <elukey>	 that follows the same pattern
[10:01:47] <mobrovac>	 elukey: that is indeed strange that .git has trebuchet:trebuchet perms
[10:02:10] <mobrovac>	 elukey: easiest way out: chown -R trebuchet:wikidev . in the deploy repo
[10:02:40] <elukey>	 yeah
[10:02:43] <mobrovac>	 the first-time set-up for scap isn't really streamlined
[10:02:57] <mobrovac>	 so let's not fight windmills here
[10:06:20] <elukey>	 :)
[10:09:28] <elukey>	 mobrovac: done, much better now
[10:09:42] <mobrovac>	 cool
[10:12:00] <elukey>	 now I have a weird 10:11:39 deploy failed: <CalledProcessError> Command '/usr/bin/git submodule foreach --recursive '/usr/bin/git update-server-info'' returned non-zero exit status 1
[10:12:13] <elukey>	 but probably some other issue more related to the repo
[10:12:17] <elukey>	 no more perm issues
[10:13:49] <elukey>	 ah yes
[10:13:50] <elukey>	 error: unable to update /srv/deployment/analytics/pivot/deploy/.git/modules/src/info/refs+
[10:14:05] <mobrovac>	 uf
[10:14:10] <mobrovac>	 the perms are all messed up there
[10:15:20] <mobrovac>	 elukey: chmod -R g+w .git in the deploy repo ought to fix it though
[10:27:52] <elukey>	 (was afk sorry, back now)
[10:28:59] <elukey>	 mobrovac: did you fix them by any chance?
[10:30:31] <elukey>	 puppet runs fine now, deploy-local on stat1001 went fine
[10:37:57] <elukey>	 no ok still broken on tin side
[10:39:33] <elukey>	 yessss now it works :) \o/
[10:43:01] <mobrovac>	 cool
[10:44:00] <mobrovac>	 i couldn't have fixed it, i don't have sudo rights on tin
[10:45:03] <elukey>	 okok
[10:59:17] <grrrit-wm1>	 (PS1) Elukey: Update src submodule's SHA [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389)
[10:59:45] <elukey>	 joal_: do you have a min?
[10:59:52] <joal_>	 elukey: I do !
[11:00:04] <elukey>	 thanks!! would you mind to double check the above code review?
[11:02:27] <elukey>	 joal_: --^
[11:02:29] <joal_>	 elukey: Just a quick headsup for me: Same idea as with aqs, right?
[11:02:42] <joal_>	 There is a pivot repo, and a pivoit/deploy repo
[11:02:59] <joal_>	 We sync up pivot repo as a submodule of pivot/deploy one
[11:03:26] <elukey>	 yes pivot is src of pivot deploy
[11:03:57] <elukey>	 the pivot systemd unit is not able to find the build dir
[11:04:11] <elukey>	 and I checked on tin that src is not the one that I need
[11:04:25] <joal_>	 I don't get this part elukey :)
[11:04:43] <elukey>	 ah ok :)
[11:05:39] <elukey>	 so basically the systemd unit responsible to run the pivot service on stat1001 is instructed to execute the build/bin/pivot script
[11:05:52] <elukey>	 but at the moment we don't have it deployed :)
[11:06:22] <elukey>	 in https://phabricator.wikimedia.org/T146389 Marcel updated the deploy repo
[11:06:33] <elukey>	 but I think he didn't follow up with the submodule change
[11:06:43] <elukey>	 so I am trying to finish the work to allow pivot to rise and shine!
[11:06:44] <joal_>	 hm
[11:06:51] <joal_>	 I think I get it :)
[11:07:19] <joal_>	 elukey: sha1 of the new src submodule is indeed the last one
[11:08:20] <joal_>	 elukey: building my understanding while checking the CR
[11:08:26] <joal_>	 sorry for the delay :)
[11:08:32] <elukey>	 we do the same with the operations/puppet submodules, because otherwise git submodules update --init does not pull the last commit but the one that it knows
[11:08:55] <elukey>	 nono please do sanity check my assumptions
[11:08:59] <elukey>	 :)
[11:09:01] <joal_>	 elukey: I recall having had that issue with aqs as well
[11:09:46] <joal_>	 elukey: Ok !
[11:09:57] <joal_>	 elukey: I'll +2 your CR :)
[11:10:03] <elukey>	 super thanks!
[11:10:12] <joal_>	 elukey: ooops, talked too fast :)
[11:10:23] <joal_>	 elukey: A better commit message would be good though :)
[11:10:33] <elukey>	 you are absolutely right
[11:10:43] <grrrit-wm1>	 (CR) Joal: [C: -1] "Please update commit message to be more explicit :)" [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389) (owner: Elukey)
[11:12:57] <grrrit-wm1>	 (PS2) Elukey: Update the src submodule's SHA [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389)
[11:14:51] <grrrit-wm1>	 (PS3) Elukey: Update the src submodule's SHA to the latest commit [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389)
[11:14:59] <mobrovac>	 elukey: joal_: the useful practice we've found useful is to have the sha1 in the commit message
[11:15:00] <elukey>	 joal_: --^ better?
[11:15:16] <mobrovac>	 like: Update src to <short-rev-sha1>
[11:15:42] <elukey>	 nice I like it!
[11:15:58] <joal_>	 elukey: I think mobrovac approach is good, but the last message you provided works for me :)
[11:16:06] <joal_>	 elukey: Ok, I let you update ;)
[11:16:54] <mobrovac>	 but if you use service-runner to build the deploy repo, it'll do it for you
[11:16:55] <mobrovac>	 :P
[11:17:05] <mobrovac>	 we can leave this discussion for another time though
[11:17:47] <grrrit-wm1>	 (PS4) Elukey: Update the src submodule's SHA to 2b19082 [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389)
[11:19:04] <elukey>	 mobrovac: yes I completely support it, and we tried but at some point Andrew and Dan suggested to proceed for the moment without it.. I think that they tried but the pivot nodejs code was a bit difficult to integrate with service runner. A good next step could be to follow up with upstream (when their repo will be available again)
[11:19:44] <elukey>	 joal_: ready!
[11:19:55] <joal_>	 elukey: Mergiiiiiing !
[11:20:00] <mobrovac>	 i'm 99% sure that the service doesn't actually need to be using service-runner in order to use it to build the dpeloy repo, though
[11:20:27] <grrrit-wm1>	 (CR) Joal: [C: 2 V: 2] "LGTM, merging." [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315067 (https://phabricator.wikimedia.org/T146389) (owner: Elukey)
[11:20:39] <joal_>	 elukey: Done !
[11:20:43] <elukey>	 this is a good point that I haven't investigated (elukey's ignorance++)
[11:20:59] <elukey>	 thanksss!
[11:38:21] <elukey>	 13:35  <icinga-wm> RECOVERY - pivot on stat1001 is OK: TCP OK - 0.002 second response time on port 9090
[11:38:24] <elukey>	 \o/
[11:41:50] <elukey>	 joal_: I moved temporarily httpd proxy rules for https://pivot.wikimedia.org to the new localhost:9090 pivot
[11:41:52] <elukey>	 on stat1001
[11:42:04] <elukey>	 but I am missing the data labels
[11:42:05] <elukey>	 weird
[11:42:12] <elukey>	 same thing for you?
[11:43:03] <joal_>	 elukey: I can't acccess http://pivot.wikimedia.org/
[11:43:18] <elukey>	 worst than me then :D
[11:43:28] <elukey>	 what do you see? error while login
[11:43:29] <elukey>	 ?
[11:45:35] <joal_>	 elukey: yes
[11:45:52] <joal_>	 elukey: It has slow to answer, but now issue is with logging
[11:46:16] <elukey>	 can  you retry?
[11:46:25] <joal_>	 elukey: sure
[11:46:39] <joal_>	 Yay :)
[11:47:24] <joal_>	 elukey: Bizarre though: everything works except for the datasource labels (fields label are ok)
[11:47:35] <elukey>	 all right now we have the same issue, good :)
[11:49:55] <elukey>	 maybe it could be firejail
[11:50:40] <elukey>	 mmm doesn't make any sense
[11:50:47] <elukey>	 and from the logs it recognizes the labels
[11:52:41] <joal_>	 elukey: :(
[11:52:48] <joal_>	 elukey: maybe some caching thing?
[11:53:50] <elukey>	 it is really weird since if you check the links on the pivot page they have the right names :D
[11:54:06] <joal_>	 elukey: Indeed !
[12:01:12] <joal_>	 AFK for a bit
[12:18:53] <joal_>	 Back
[12:21:45] <elukey>	 Oct 10 12:21:34 stat1001 firejail[27954]: Got the latest time for 'pageviews-daily' (2016-09-30T00:00:00.000Z)
[12:21:48] <elukey>	 Oct 10 12:21:34 stat1001 firejail[27954]: Got the latest time for 'edit-history-test' (2016-09-07T21:47:21.000Z)
[12:21:51] <elukey>	 Oct 10 12:21:34 stat1001 firejail[27954]: Got the latest time for 'pageviews-hourly' (2016-10-09T23:00:00.000Z)
[12:22:05] <elukey>	 maybe firejail somehow filters them?
[12:22:47] <elukey>	 ah snap the logs are going to sysllog
[12:25:50] <elukey>	 moritzm: question for you about firejail if you have time :)
[12:28:03] <moritzm>	 sure
[12:28:59] <elukey>	 thanks! So the pivot nodejs service is now running fine on stat1001, rendering https://pivot.wikimedia.org/#
[12:29:31] <elukey>	 you can log in if you want with you Wikitech credentials
[12:30:06] <elukey>	 basically the javascript should display pageviews-daily, edit-history-test and pageviews-hourly rather than "no description available"
[12:30:16] <elukey>	 the info are retrieved on the fly from druid
[12:30:42] <elukey>	 and with the "screen" version on stat1002 this problem was never noticed
[12:30:47] <moritzm>	 having a look
[12:30:52] <elukey>	 thanks!
[12:31:07] <elukey>	 just wanted to know if in your opinion there might be something trivial to fix
[12:36:44] <moritzm>	 can I restart pivot.service for debugging?
[12:37:08] <elukey>	 sure
[12:37:16] <moritzm>	 ok
[12:43:22] <moritzm>	 this is unrelated to firejail, I tried minimising the profile and also removing firejail from the systemd unit entirely, made no diffeence
[12:43:46] <moritzm>	 also added some ferm logging to druid1001 to see whether there's anything possibly dropped, but didn't happen either
[12:44:25] <moritzm>	 not sure what's going on here, where does it pull "pageviews-daily" from?
[12:44:39] <elukey>	 oh wow thanks a lot, I was about to do something similar but you anticipated me, sorry for the extra work :)
[12:45:02] <elukey>	 it should pull them from druid itself, while connecting
[12:45:12] <elukey>	 probably a but somewhere in pivot
[12:45:32] <moritzm>	 maybe it's a setting in druid somewhere
[12:45:42] <moritzm>	 that it still expects stat1002 somewhere or so
[12:46:13] <elukey>	 will check, thanks again!
[12:46:37] <moritzm>	 yw
[13:05:16] <ottomata>	 mornin!
[13:06:15] <elukey>	 hola! o/
[13:06:25] <ottomata>	 hiiiiii
[13:06:31] <ottomata>	 who's workin today? cause I am!
[13:06:42] <joal_>	 heya ottomata :)
[13:06:45] <joal_>	 I am as well
[13:08:38] <ottomata>	 yeehaw
[13:08:49] <ottomata>	 sounds like enough for a standup to me!  i miss yall!
[13:09:02] <joal>	 huhuhu
[13:09:04] <joal>	  :)
[13:09:13] <elukey>	 :)
[13:11:07] <elukey>	 ottomata: whenever you have time can we chat about the kafka broker list in hiera? Varnishkafka is spamming that kafka1018 is not reachable (librdkafka complains) and also Brandon found https://gerrit.wikimedia.org/r/#/c/267243/ (never reverted)
[13:12:24] <elukey>	 should we update also puppet when a broker is down? WDYT?
[13:13:21] <ottomata>	 elukey:  hmMmmmM, since the list is used for bootstrapping, i would say we shouldn't
[13:13:29] <ottomata>	 but, it seems some clients are annoying if a broker is down
[13:13:37] <ottomata>	 maybe we should use lvs?
[13:13:42] <ottomata>	 pool/depool?
[13:13:44] <ottomata>	 instead of puppet?
[13:13:45] <ottomata>	 hmm
[13:13:53] <ottomata>	 not sure if that is possible
[13:14:53] <elukey>	 confd could be used but it might be a bit overkill
[13:15:24] <wikibugs>	 Analytics-Kanban: Migrate the simplest limn dashboards to dashiki tabular {frog} - https://phabricator.wikimedia.org/T126358#2703620 (mforns) a:mforns
[13:16:48] <grrrit-wm1>	 (Abandoned) Mforns: [WIP] Add 2 wikistats reports [analytics/reportupdater-queries] - https://gerrit.wikimedia.org/r/311961 (https://phabricator.wikimedia.org/T141479) (owner: Mforns)
[13:17:13] <ottomata>	 yeah
[13:17:32] <ottomata>	 elukey:  i think if we know the broker is going to be down for long enough (like this one) then it'd be fine to take it out of hiera
[13:22:07] <elukey>	 !log moved pivot apache vhost to localhost:9090
[13:22:39] <elukey>	 ottomata: all right, maybe we can discuss post-standup?
[13:22:49] <ottomata>	 aye k
[13:23:21] <elukey>	 so the new pivot daemon on stat1001 works fine
[13:23:27] <elukey>	 except the front page of https://pivot.wikimedia.org/#
[13:23:48] <elukey>	 I am not sure why it is not displaying the labels
[13:45:40] <elukey>	 joal: pivot on stat1002 is 0.8.34 meanwhile on stat1002 is 0.9.39
[13:45:50] <joal>	 hmmmmm
[13:45:59] <elukey>	 sorry the first is stat1002 the second stat1001
[13:46:23] <elukey>	 so 0.9.39 seems to have a bug
[13:46:24] <joal>	 k elukey
[13:46:32] <joal>	 mwarf :(
[13:52:35] <grrrit-wm1>	 (PS1) Elukey: Add scap configuration to restart the Pivot service after deploy [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315092 (https://phabricator.wikimedia.org/T146389)
[13:52:54] <grrrit-wm1>	 (CR) Elukey: [C: 2 V: 2] Add scap configuration to restart the Pivot service after deploy [analytics/pivot/deploy] - https://gerrit.wikimedia.org/r/315092 (https://phabricator.wikimedia.org/T146389) (owner: Elukey)
[14:11:15] <mforns>	 hi team :]
[14:11:17] <mforns>	 milimetric, yt?
[14:11:44] <elukey>	 mforns: o/
[14:11:46] <milimetric>	 hi mforns, what's up
[14:12:01] <milimetric>	 it's a holiday here
[14:12:36] <mforns>	 milimetric, I'm reviewing a candidate's task and trying to execute es6 on node, have you done it before? I'm having problems
[14:12:59] <mforns>	 milimetric, oh!!! sorry then
[14:13:09] <elukey>	 mforns: whenever you have time can we chat about https://pivot.wikimedia.org? The version on the gerrit repo, that I've deployed to stat1001 via scap, is 0.9.39 meanwhile the one running in screen on stat1002 is 0.8.something
[14:13:12] <mforns>	 go have fun :]
[14:13:20] <milimetric>	 Yeah, you need that harmony extension thing or something, or to compile it with Babel or some nonsense like that
[14:13:31] <elukey>	 mforns: and there is a visualization bug of the data labels :(
[14:13:47] <mforns>	 milimetric, ok, thanks, in nodejs' site it says you don't but anyway, thanks!
[14:13:53] <milimetric>	 but nice, I like the effort!  Also, ottomata might know, he's doing latest js on node
[14:14:00] <mforns>	 ok
[14:14:43] <mforns>	 elukey, sure, whenever you want
[14:15:15] <milimetric>	 elukey: I can try pulling in more recent changes to my fork, see if it fixes it.  We can do that tomorrow?
[14:15:58] <milimetric>	 But yall can do it on the gerrit repo.  Let me know if you want push to my github, just in case
[14:16:00] <elukey>	 milimetric: sure! everything works fine now I just wanted to know what do to with the bug :)
[14:16:12] <elukey>	 reverting to 0.8.x, etc..
[14:16:14] <elukey>	 no hurry
[14:16:32] <milimetric>	 I wouldn't worry, especially if it's easy to upgrade I can pull tomorrow and do that
[14:16:35] <elukey>	 I assumed that the version on stat1002 and on the repo was the same
[14:16:41] <elukey>	 sure sure
[14:16:43] <elukey>	 thanks!
[14:16:55] <mforns>	 thx
[14:33:05] <elukey>	 just created https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Druid#Pivot_Administration
[14:51:57] <elukey>	 ottomata: I had a chat with Erik Zachte about statistics::wikistats, more specifically the stat1-cron-script.sh cron
[14:52:12] <elukey>	 he said that it is a very old script that could be deprecated
[14:52:35] <elukey>	 but afaics the statistics::wikistats class is there for the cron right?
[14:52:42] <elukey>	 so we could in theory nuke it entirely
[14:52:59] <elukey>	 (or maybe only the cron)
[14:54:31] <ottomata>	 !
[14:54:39] <ottomata>	 elukey:  anything we can nuke there I am for
[14:59:46] <elukey>	 ottomata:
[14:59:47] <elukey>	 https://gerrit.wikimedia.org/r/#/c/315101/1
[14:59:52] <elukey>	 maybe this one as starter
[14:59:57] <elukey>	 :)
[15:00:13] <nuria>	 ni ce elukey thanks for the docs
[15:01:00] <nuria>	 a-team: standduppp
[15:01:56] <ottomata>	 coming...
[15:37:55] <wikibugs>	 Analytics, Analytics-EventLogging: Ensure no dropped messages in analytics eventlogging processors when stopping broker - https://phabricator.wikimedia.org/T142430#2703856 (Nuria) a:Ottomata
[15:41:06] <wikibugs>	 Analytics: Puppetize job that saves old versions of geoIP database - https://phabricator.wikimedia.org/T136732#2703862 (Nuria) @Milimetric : should we do this or rather kill cron and task? We have not had the need  to do this thus far (in two years).
[15:46:26] <wikibugs>	 Analytics, New-Readers, Easy: Split opera mini in proxy or turbo mode - https://phabricator.wikimedia.org/T138505#2703880 (Nuria)
[15:48:28] <wikibugs>	 Analytics, Pageviews-API, Easy: Add monthly request stats per article title to pageview api - https://phabricator.wikimedia.org/T139934#2703889 (Nuria)
[15:56:28] <wikibugs>	 Analytics: Pre-generate mysql ORM code for sqoop - https://phabricator.wikimedia.org/T143119#2557510 (Nuria) @Milimetric : is this still relrevant for Q2 if we run scoop once a week?
[15:57:42] <wikibugs>	 Analytics, Easy: Don't accept data from automated bots in Event Logging - https://phabricator.wikimedia.org/T67508#2703917 (Nuria)
[16:00:28] <wikibugs>	 Analytics, Pageviews-API: Improve user management for AQS - https://phabricator.wikimedia.org/T142073#2703934 (Nuria)
[16:10:31] <grrrit-wm>	 (CR) Nuria: [C: 2 V: 2] "Merging, will be deployed this week." [analytics/refinery] - https://gerrit.wikimedia.org/r/311964 (https://phabricator.wikimedia.org/T146064) (owner: Nschaaf)
[16:12:53] <elukey>	 ottomata: so PROBLEM - Kafka MirrorMaker main-eqiad_to_analytics on kafka1012 is CRITICAL: PROCS CRITICAL: 0 happened on Oct 4th
[16:12:59] <elukey>	 and I restarted it manually
[16:13:06] <elukey>	 but I also have other recurrences
[16:14:00] <elukey>	 ah yes the ones from kafka1018
[16:26:37] <ottomata>	 hm, interesting
[16:26:39] <ottomata>	 anything in logs elukey?
[16:28:18] <elukey>	 I should have opened a phab dask sigh
[16:28:27] <elukey>	 maybe journalctl has still some logs
[16:29:11] <elukey>	 yes!
[16:29:42] <elukey>	 so ottomata - [2016-10-04 07:13:54,513] on kafka1012, sudo journalctl -u kafka-mirror-main-eqiad_to_analytics.service
[16:43:53] <ottomata>	 hm, interesting, looks like it couldn't produce at some point
[16:44:02] <ottomata>	 and now it doesn't have any conusmer groups assigned
[16:44:16] <ottomata>	 am headed to a cafe, bbs
[17:13:00] <elukey>	 going afk team! talk with you tomorrow!
[17:13:01] <elukey>	 o/
[17:21:17] <ottomata>	 laters!
[17:35:30] <wikibugs>	 Analytics: Missing raw pageview data for 7/29/2015 - 03:00 - https://phabricator.wikimedia.org/T147801#2704063 (Nuria)
[18:55:17] <nuria>	 elukey: (for tomorrow) changed commit msg , let me know if it is Ok to merge: https://gerrit.wikimedia.org/r/#/c/314722/
[19:54:27] <mforns>	 nuria, do you know how the apache config in dashiki-01 is altered? directly editing /etc/apache2/sites-available/50-simplestatic.conf?
[19:54:47] <nuria>	 mforns: yes, there is a git depot local to teh box with a bunch of commits
[19:54:50] <nuria>	 *the
[19:55:17] <nuria>	 mforns: ah sorry, no
[19:55:25] <nuria>	 mforns: i read *limn* somehow
[19:55:39] <milimetric>	 it's a hiera puppet config in wikitech
[19:55:47] <nuria>	 mforns: we are talking the new good config? if so it is hiera
[19:55:51] <nuria>	 right,
[19:56:02] <mforns>	 ok milimetric thanks
[19:56:11] <mforns>	 :]
[20:17:45] <grrrit-wm>	 (PS7) Nuria: [WIP] Service Worker to cache locally AQS data [analytics/dashiki] - https://gerrit.wikimedia.org/r/302755 (https://phabricator.wikimedia.org/T138647)
[20:34:15] <grrrit-wm>	 (PS8) Nuria: [WIP] Service Worker to cache locally AQS data [analytics/dashiki] - https://gerrit.wikimedia.org/r/302755 (https://phabricator.wikimedia.org/T138647)
[20:42:02] <mforns>	 nuria, :] I see very few data in http://glam-metrics.wmflabs.org, and it is not updated any more. Do we want to keep it as historical reference? Also, there is a world-map chart, is the idea to create a new visualizer in dashiki, or should be represent it in another way?
[20:43:47] <nuria>	 mforns: given that data is pretty old (2014?) and note updated since then ( am I right?) i vote for kill
[20:44:17] <nuria>	 mforns: dashiki needs a map yes, but I am not sure it needs one for this project
[20:44:28] <nuria>	 mforns: i think we will need to develop one eventually
[20:47:05] <grrrit-wm>	 (PS1) Nuria: Changing link to browsers to avoid a 301 [analytics/analytics.wikimedia.org] - https://gerrit.wikimedia.org/r/315184
[20:47:13] <mforns>	 nuria, aha, agree, but since dan listed it as to move to dashiki, I guess there is a reason to it no? although it's pretty old...
[20:47:48] <nuria>	 cc milimetric but .. i do not think so.. I think at the time we though data was updating
[20:47:56] <nuria>	 we can talk about this tomorrow
[20:49:10] <mforns>	 nuria, ok :]
[20:50:01] <nuria>	 mforns: take a look at this small change: https://gerrit.wikimedia.org/r/#/c/315184/
[20:50:15] <nuria>	 mforns: I think it will avoid 1 extra redirect in the dashboards
[20:50:20] <mforns>	 nuria, ok
[20:50:29] <nuria>	 mforns: thank you
[21:00:33] <grrrit-wm>	 (CR) Mforns: [C: 2 V: 2] Changing link to browsers to avoid a 301 [analytics/analytics.wikimedia.org] - https://gerrit.wikimedia.org/r/315184 (owner: Nuria)
[21:00:48] <mforns>	 nuria, cool