Connect a subset of iodide production instance tables to redash
Categories
(Cloud Services :: Iodide, task, P2)
Tracking
(Not tracked)
People
(Reporter: wlach, Assigned: robotblake)
Details
(Whiteboard: [DataOps])
We should connect redash to our production iodide database (the one powering iodide.telemetry.mozilla.org) so we can analyze various things about internal usage, for example:
- Which notebooks have many edits
- How many active notebooks we have
- Most frequent users
To start with I think we only need access to the following tables:
base_user (note: exclude the password, is_superuser, is_staff fields)
notebook
notebook_revision
This is similar to what we did with treeherder way back when in bug 1279580.
I think this is slightly lower priority than getting the production server fully up and running, but it would be nice to have this shortly after.
|
Reporter | |
Comment 1•6 years ago
|
||
Hey Blake, what would it take to get this implemented? I'm hoping it would be pretty easy?
|
Assignee | |
Comment 2•6 years ago
|
||
I don't think it'd be too difficult.
Steps we'd need to take:
- Make sure the db instance has an external IP.
- Allow ingress traffic from the Redash external IPs.
- Create a new RO user with access to just those tables.
- Add the data-source to Redash.
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 3•6 years ago
|
||
I created the user for this but never got it added properly, that's now been done but it seems there are issues with the schema viewer. When I manually run the query from https://github.com/mozilla/redash/blob/m26/redash/query_runner/pg.py#L158-L181 it does work though so there appears to be something up with how the schema refresh is happening.
It's listed as the Iodide data source in Redash.
I'm going to close this but we should probably open up a new one for the issues we're seeing.
Description
•