[14:43:10] <average>	 hey, I have a question
[14:43:21] <average>	 if dclass has a bug, but dclass is not our product, but we do use it..
[14:43:29] <average>	 uhm, does that mean that I can report the bug in bugzilla ?
[14:43:35] <average>	 so we can track it there ?
[14:46:56] <average>	 ottomata , milimetric can I ask your oppinion on this ? ^^
[14:49:09] <milimetric>	 sure average
[14:49:10] <milimetric>	 shoot
[14:49:28] <milimetric>	 oh
[14:49:35] <milimetric>	 you should probably report it wherever they take issues
[14:49:48] <milimetric>	 like github issues, their bugzilla, whatever
[14:50:02] <milimetric>	 and then link to it from any task / bugzilla bug you're working on that's blocked by the issue
[14:50:18] <milimetric>	 then maybe do a pull request?
[14:50:34] <average>	 that would be github(where they keep issues) https://github.com/TheWeatherChannel/dClass/issues
[14:51:00] <average>	 ok
[14:51:13] <grrrit-wm>	 (PS11) Stefan.petrea: [DO NOT SUBMIT] [WIP] kraken-hive UDFs [analytics/kraken] - https://gerrit.wikimedia.org/r/96738 (owner: QChris)
[14:52:16] <milimetric>	 ha! I had no idea this was the weather channel's thing
[14:52:16] <milimetric>	 yeah, I'd file an issue there
[14:52:16] <milimetric>	 and if it's blocking you + the fix is easy, do a pull request
[14:53:01] <average>	 the fix is not easy
[14:54:01] <drdee_>	 just curious, what's the bug?
[14:59:53] <average>	 drdee_: when we tried to do the upgrade of the dtree file, back in summer-autumn last year, the tests broke. in particular a device that has model A6380 is now identified as having model A6366 . initially we thought this was due to the big device drop in OpenDDR 1.15(see page 2 here http://garage-coding.com/new-draft-c9a36eb3c2217b3326373ced3736baf2.pdf ) but after looking closer at dtrees after the drop they contain both the old device A6
[15:00:32] <drdee_>	 mmmm interesting
[15:01:36] <average>	 hey qchris
[15:01:51] <qchris>	 hi average... Daily scrum :-)
[15:02:31] <ottomata>	 qchris HIIiIAIAIAIAII
[16:15:22] <halfak>	 Ping tnegrin
[17:19:29] <halfak>	 Anyone within throwing distance of DarTar?
[17:30:44] <grrrit-wm>	 (PS1) Milimetric: Adds alembic migrations [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220
[17:31:21] <milimetric>	 nuria, csalvia: alembic migrations added: https://gerrit.wikimedia.org/r/#/c/111220/
[17:31:25] <milimetric>	 please review
[17:31:43] <milimetric>	 note: milimetric feels stupid for not adding this earlier
[17:31:44] <milimetric>	 :)
[17:31:52] <nuria>	 that was FAST
[17:32:13] <nuria>	 BTW, added bug card with all set https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/1430
[17:32:23] <nuria>	 but not showing in scrum planning like it should
[17:33:33] <ottomata>	 haha migrations, yay!
[17:33:34] <ottomata>	 :)
[17:34:55] <grrrit-wm>	 (CR) Ottomata: "No initial migration yet?" [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220 (owner: Milimetric)
[17:35:07] <ottomata>	 oh i don't know how alembric works though
[17:35:10] <ottomata>	 ignore me
[17:35:17] <ottomata>	 maybe it just infers from models
[17:35:50] <milimetric>	 hm, right, so if there's nothing at all in the databases, then sql alchemy creates it as part of get_session
[17:36:02] <milimetric>	 I'm not 100% sure if that's kosher but it seems ok otto
[17:37:38] <ottomata>	 cool as long as env != produciton :p
[17:41:46] <grrrit-wm>	 (CR) Milimetric: "initial migration - the way wikimetrics has worked so far is to let sqlalchemy create the schema if it doesn't exist. So the mysql script" [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220 (owner: Milimetric)
[17:42:29] <milimetric>	 yeah, ottomata, I think you have a point and we have to figure it out before merging
[17:48:37] <grrrit-wm>	 (PS2) Milimetric: Adds alembic migrations [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220
[18:02:28] <nuria>	 if there are no tables running alembic revision --autogenerate creates them too
[18:03:51] <nuria>	 ottomata: is that not good enough?
[18:52:33] <grrrit-wm>	 (PS3) Nuria: [WIP] Changes tu support wikimetrics in vagrant. [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/109676
[20:16:56] <diegolo>	 /query peppe
[20:16:57] <diegolo>	 sorry
[21:30:39] <grrrit-wm>	 (PS3) Milimetric: Adds alembic migrations [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220
[21:31:25] <milimetric>	 k nuria / csalvia_ the alembic change is ready for merge, complete with an initial revision per ottomata's comments
[21:31:35] <milimetric>	 I'll add reviewers
[21:31:52] <nuria>	 ok
[21:35:36] <nuria>	 let me get the changeset and test
[22:01:39] <grrrit-wm>	 (CR) Nuria: [C: 1 V: 1] "I think we might need to reword the README a bit to make clear that user should skip this 1st step: mysql -uwikimetrics -pwikimetrics < sc" [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220 (owner: Milimetric)
[22:08:41] <grrrit-wm>	 (PS4) Milimetric: Adds alembic migrations [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220
[22:09:52] <grrrit-wm>	 (CR) Nuria: "I think we need to test the scenario of adding a column to an 'existing' db. That brought up some errors, will re-test." [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220 (owner: Milimetric)
[22:10:31] <milimetric>	 hm, can you be specific nuria?
[22:10:44] <milimetric>	 I've updated the wording
[22:10:56] <milimetric>	 but how did you get into trouble with the migrations?
[22:11:11] <nuria>	 i just tried added a column and running after:
[22:11:29] <milimetric>	 note: if you manually delete files from the versions folder, you could get into a inconsistent state
[22:11:31] <nuria>	 alembic revision --autogenerate -m "test"
[22:11:38] <milimetric>	 where did you add the column?
[22:11:45] <nuria>	 alembic upgrade head
[22:11:56] <nuria>	 to cohorts.py
[22:12:09] <milimetric>	 ok
[22:12:13] <milimetric>	 and then what happened
[22:12:16] <nuria>	 qlalchemy.exc.OperationalError: (OperationalError) (1050, "Table 'user' already exists") '\nCREATE TABLE user (\n\tid INTEGER NOT NULL AUTO_INCREMENT, \n\tusername VARCHAR(50), \n\temail VARCHAR(254), \n\trole VARCHAR(50), \n\tgoogle_id VARCHAR(254), \n\tmeta_mw_id VARCHAR(254), \n\tauthenticated BOOL, \n\tactive BOOL, \n\tPRIMARY KEY (id), \n\tCHECK (authenticated IN (0, 1)), \n\tCHECK (active
[22:12:17] <nuria>	  IN (0, 1))\n)\n\n' ()
[22:12:30] <milimetric>	 do select * from alembic_version;
[22:13:45] <nuria>	 it's empty
[22:14:13] <milimetric>	 right
[22:14:20] <milimetric>	 so then script 99 must not have worked
[22:14:21] <nuria>	 so it is replaying all changes
[22:14:32] <milimetric>	 you ran this:
[22:14:47] <milimetric>	 mysql -uwikimetrics -pwikimetrics < scripts/99_...
[22:14:48] <milimetric>	 ?
[22:16:19] <nuria>	 i thought i did but i must have not done it. just tried again and it all worked.
[22:16:25] <nuria>	 tried both cases
[22:16:38] <nuria>	 1) fresh install 2) added column ti existing db
[22:16:44] <nuria>	 both worked
[22:17:52] <milimetric>	 cool
[22:18:00] <milimetric>	 yeah, i double checked and it all worked for me too nuria
[22:18:13] <milimetric>	 alembic is smarter than us and we only gave birth to it a few hours ago :)
[22:18:15] <milimetric>	 awww
[22:18:30] <nuria>	 +2 then I guess
[22:18:55] <milimetric>	 cool
[22:19:15] <milimetric>	 hopefully it won't be too crazy to pull this into any currently relevant gerrit Change and go from here
[22:19:27] <milimetric>	 I'll base my stuff on master after you or charles merges this
[22:20:35] <nuria>	 i will merge it to master and pull it into the vagrant branch
[22:21:05] <milimetric>	 cool
[22:21:11] <milimetric>	 do you pull --rebase when you do that?
[22:21:35] <milimetric>	 (no opinion either way, just curious)
[22:25:01] <grrrit-wm>	 (CR) Nuria: [C: 2 V: 2] "Looks like both wikimetrics fresh install and addition of fields to existing models work well via alembic." [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/111220 (owner: Milimetric)