Funny enough, both this and D787 were needed to make the fixed width change work. But I think it's just 'cause of the svg.attr('width'). So I'll accept both and move to review. Now there's still a slightly annoying thing that the height is changing based on the labeling, so the time selector controls jump around a bit. This is minor, we can figure something out later.

gotcha, editing comment

Still a few problems:

This works ok from a data point of view, but there are two rendering problems:

All of these have been addressed, good.

The widget now seems to compute the average at all times, but the pageviews metric is additive, so it could show the yearly total instead.

The table view doesn't work for this metric on the Detail page.

Line graph works on the Detail page

The first part of the task, dealing with "Something - All Languages" no longer applies. We disabled this until we have endpoints for it in AQS.

verified working and php beacon is gone

"why this session and what is its target? What do we want to achieve with it?"

Looks like this is resolved, at least files were written after the date of the bug, @Erik_Zachte anything you need help with before closing the task?

Well, that was easy. https://gerrit.wikimedia.org/r/#/c/371218/ fixed it. Sorry for the noise.

once you authenticate, and if you can construct the post the way it expects it, then yes, you can POST to /cohorts/upload

Someone could change the code to do that, but right now you need to be authenticated to access /cohorts/upload

Good news, the 2017-07_private snapshot finished. I will now start the 2017-07 snapshot process, and if there are no problems that should be available before the end of Wikimania as well.

I think I worked out the bugs, should be ready soon unless something else goes wrong.

No rush but just a heads up to @Neil_P._Quinn_WMF, the 2017-07_private job failed and I'm not sure what's wrong.

@Marostegui: thank you, I confirm the problem is addressed. In the meantime, we decided to just run the 2017-07_private snapshot, @Neil_P._Quinn_WMF. This should be done someone this weekend and available Monday, with all wikis available pulled from production. And we'll re-run the 2017-07 snapshot from labs later this month when @Marostegui tells us the rest of the wikis are imported and ready to be used. (At that time I'll be on leave so you'll be talking to @JAllemandou). Thanks all!

The jobs that didn't run were identified in T165233#3498662 and the error seems to have to do with database access, so for now I'm moving this to done and deploying the new version of the sqoop script. Since I don't think it makes sense to wait and sqoop the remaining wikis, I'm going to manually add the success flags in order to trigger the snapshot for this month.

Hm, @Marostegui I need some help. I ran the sqoop job to import from all the wikis except the ones you mentioned in T165233#3486500. I get access denied errors:

In general in the future you should mention how to test a change. In this case the default screen doesn't have unique devices data (because there is none for all-projects), so you should mention it needs to be tested on a specific wiki or something like that.

Ok, I just deployed the list for all but the 12 wikis that are still imported. That means the next reconstruction will have data from everything except those 12. (Centralauth isn't used in reconstruction).

Yes, Special:Version@meta links to https://www.mediawiki.org/wiki/Extension:Dashiki. The auto-added link to phabricator is broken because there's no phab mirror of the gerrit mediawiki-Dashiki repository. I'm not sure what the right procedure is there, it's not my area.

@MarcoAurelio: rANAD is not an extension, it's only related to mediawiki-Dashiki by the word "Dashiki". Which, in this context, means "dashboards on wikis". It's a system that allows people to build dashboards by writing a wiki page as a configuration. For example, this dashboard:

Just to keep the archives happy, yes, we're using Differential for code review.

priorities have sadly shifted a bit, I may not be able to get to this. cc @Nuria.

Thanks @Aklapper, I support @gdusbabek's NDA request. His team has a lot of experience with the technology we work with and we would both benefit from collaboration. I'm cc-ing and assigning this to Nuria as per https://wikitech.wikimedia.org/wiki/Volunteer_NDA#Get_support.

Thanks @greg, added info for EventBus. This is a good resource to keep updated.

In my opinion, we could remove vue-router as a dependency and use just a simple component that mirrors some property from the $store to the url and vice versa. That's what I had in mind with cleaning up the routing code. This way, whenever we add something that needs to be mirrored to the URL, it's a small change in the $store and the routing continues to work. It would also make the source smaller because vue does a bunch of stuff we don't need.

Oh, gotcha. Agreed. Am I right in guessing that the Structured Data work would make JsonConfig obsolete and we can migrate to that once it's ready? Or is that just enabling multiple types of content, and not necessarily solving the problem of storing Json specifically? If so, then maybe we have to learn JsonConfig. It doesn't seem too terribly complicated, maybe we I can pair with someone and the two of us can be responsible for it.

No, I wrote this extension. I know this code inside and out, because it's like five lines, and there's no problem in the code itself as far as we can tell, just in how JsonConfig expects it to provide something in extension.json. I couldn't replicate the problem we see in production, so I don't know how to fix it except for the "test in production" advice I got above - which definitely freaks me out.

I couldn't replicate in vagrant or beta, though I tried. I'm all up for sitting with someone who knows mediawiki better to try and debug. This extension itself is about as simple as an extension can get, it's basically a Hello World using JsonConfig classes.

it's good that it worked, Goran. Stat1005 is not yet fully vetted and ready to go, so we don't expect everything to work there yet.

The analytics ones (analytics, dashiki, reportcard) no longer need it, we should clean that up, but I'm a bit hesitant to start anything new now before parental leave.

Here is a template for how to do this in general. The example is using a test directory in hdfs under my user, and the cewiki database.

Yeah, it's kind of a bug in Phabricator that it copies all parent tags on subtasks. I think that's causing a ton of unwanted pinging. It would be fine if there was an option like "copy parent tags" but leave them off by default.

I mean, whether it's Python or R has nothing to do with the access level. My point is, there's an example of a sqoop script there, that works when run either as hdfs or as an unprivileged user. So we can use that as a starting point. Now, if you could explain what you would like to do ideally, that would be a good starting point. As I was saying, it's hard to figure out from the long thread above.

@GoranSMilovanovic I pinged you in IRC but in case you missed it, let's meet to go over the problem here. I wrote the sqoop job that loads all mediawiki tables into HDFS: https://github.com/wikimedia/analytics-refinery/blob/master/bin/sqoop-mediawiki-tables and I should be able to help. But I need to know exactly what you're trying to do, and I lost context with this long thread.

One version of the history schema simplified and loaded to test how Druid can work as a direct back-end for AQS: