[00:05:57] madhuvishy: back [00:06:14] nuria: I put a print in the sql handler [00:06:21] aham [00:06:59] nuria: like [00:07:02] https://www.irccloud.com/pastebin/F0YAKuGl/ [00:07:09] now this shows up [00:07:12] for everything [00:07:28] except this specific revision of the analytics schema [00:07:37] it makes no sense [00:07:40] madhuvishy: jaja [00:07:43] madhuvishy: boy ... [00:08:01] madhuvishy: let's do a different test [00:08:09] madhuvishy: let's drop the table for old schema [00:08:17] madhuvishy: and send events for that table [00:08:21] *that schema [00:08:23] nuria: am i missing something when I update a schema? I changed the wiki page - got a new revision number - and tried to send events to the new revision [00:08:33] nuria: alright [00:08:39] madhuvishy: no, i saw your events on all-events [00:08:48] nuria: yes! and kafka [00:08:50] anyway [00:08:56] madhuvishy: 1 by 1 [00:09:04] madhuvishy: let's test autoincrement table creation [00:09:13] nuria: ya okay [00:10:55] madhuvishy: try that and let me know [00:19:04] nuria: no table [00:19:12] madhuvishy: and no logging? [00:21:19] madhuvishy: makes no sense cause i dropped a table just recently to test toku db in beta (just last week) [00:21:27] madhuvishy: and it got created np [00:21:44] nuria: I see logs from the handler [00:21:48] but not from jrm.py [00:22:08] nuria: yeah! I sent data to a non existent table yesterday [00:22:11] madhuvishy: did you log with print? [00:22:14] and the table got created [00:22:20] no - i used logging [00:22:28] in both places [00:22:29] so [00:23:14] madhuvishy: ok let's rollback your change & build & stop and restart [00:23:29] madhuvishy: and try to create table again [00:23:37] nuria: it may be the mysql tokudb thing [00:23:38] hold on [00:23:48] k [00:26:52] nuria: okay [00:26:55] it was that [00:27:00] aham [00:27:04] default_storage_engine inside the file [00:27:14] default-storage-engine is the command line option [00:27:15] my.cnf [00:27:22] ah ok [00:27:24] i did not know that [00:27:33] so there was an innodb vs tokudb [00:27:36] nuria: although - the dropped table got created [00:27:48] i think the default in my.cnf before was Aria [00:27:49] in 300 ms [00:28:06] but - I dont see the new revision table being created [00:28:07] yet [00:28:31] or showing up in the logs [00:28:35] so that part is weird [00:28:41] ok so table with old schema got created ok [00:28:48] yes [00:28:54] with autoincrement id [00:29:13] yup! [00:29:20] let me look at schema versions, what is schema AnalyticsTest? [00:29:39] https://meta.wikimedia.org/wiki/Schema:Analytics [00:29:45] https://meta.wikimedia.org/wiki/Schema:Analytics [00:29:46] yes [00:29:59] nuria: I added the height field today [00:30:07] 15332607 is the new revision [00:30:24] 13317883 is the old one [00:31:58] boy i ahve no explanation [00:32:00] *have [00:33:27] nuria: me too - and it seems to not even be tied with this autoincrement change [00:33:53] madhuvishy: yaaaa, not only that events are duplicated in beta labs, but that could be varnish [00:34:18] nuria: ah yes [00:34:25] hmmmm [00:35:08] madhuvishy: but i already verfied msgs are duplicated in kafka topic [00:35:16] eventlogging_valid_mixed [00:37:40] nuria: ah yes i also see some repetition in the logs - but this new revision events not showing up is weirdd [00:37:52] madhuvishy: but they show up in logs [00:38:10] nuria: not in the mysql handler logs though [00:38:19] they get inserted everywhere but mysql [00:38:23] madhuvishy: right, right, they show up on all events log [00:38:30] yup [00:38:53] they get all the way eventlogging_Analytics - and for some reason the mysql consumer ignores them [00:40:00] madhuvishy: i think i know [00:40:07] nuria: oh? [00:40:14] {"clientIp": "08148e4cbe16649292dfe542124ee80292070454", "event": {"height": 31, "name": "yC"}, "recvFrom": "29", "revision": 15332607, "schema": "Analytics", "seqId": 121643, "timestamp": 1455050642, "userAgent": "\"-\"", "uuid": "718a4f5eda685c5c909bf54a2e10166d", "wiki": "Xe"} [00:40:19] height doesn't have quotes [00:40:32] nuria: why should it? [00:41:01] nuria: also if it's a validation issue why will it be valid anyway [00:41:04] madhuvishy: ah no, it is a number [00:41:13] madhuvishy: ya, validation according to schema is ok [00:41:13] yes [00:41:45] madhuvishy: but even then the json of the schema needs to be parsed as text to be inserted [00:42:16] madhuvishy: but no, as long as it is a number (which it is) [00:42:19] that is fine [00:44:44] madhuvishy: and you also have logging to table lookup [00:46:31] madhuvishy: there are exceptions on the logging though: [00:46:33] https://www.irccloud.com/pastebin/cHP2XwuX/ [00:46:46] that will kill the thread [00:48:03] madhuvishy: see: 2016-02-09 21:56:49,144 (MainThread) Driving [00:48:04] kafka:///deployment-kafka02.deployment-prep.eqiad.wmflabs:9092?topic=eventlogging-valid-mixed&blacklist=^Analytics|CentralNoticeBannerHistory$&zookeeper_connect=deployment-zookeeper01.eqiad.wmflabs/kafka/analytics-deployment-prep&auto_commit_enable=True&auto_commit_interval_ms=1000&auto_offset_reset=-1&identity=mysql-m4-master -> [00:48:04] mysql://eventlogging:68QrOq220717816UycU1@127.0.0.1/log?charset=utf8&statsd_host=labmon1001.eqiad.wmnet&replace=True.. [00:48:21] analytics is on the blacklisted list? [00:50:32] madhuvishy: ok, that must be it [00:51:19] madhuvishy: did your removed teh blacklist? [00:52:41] nuria: really? no i dint but the old revision events went through [00:53:17] madhuvishy: analytics table event #1 is | 1 | 1e0405e0bb865a529ac26958f1b9fbcb | a6fc10fe8efa9e47f5ecf23e8491229bb866ed72 | 20160209025919 | "-" | NULL | yv | 67 | YY | [00:53:30] with date 20160209025919 [00:54:07] let's drop that table again, how were you generating events? [00:54:11] nuria: right - the old one [00:54:50] nuria: i'm using the eventlogging-load-tester script [00:55:00] madhuvishy: k [00:55:02] like [00:55:05] python bin/eventlogging-load-tester -s 'Analytics:15332607:1' --optional-values always 10 [00:55:13] this is for new revision [00:55:18] nuria: this table doesn't exist [00:55:28] so i agree its part of the blacklist [00:55:35] right [00:55:45] but i dont understand how it got created for the old revision yesterday [00:56:17] madhuvishy: ya... [00:56:51] madhuvishy: i dropped table, it should not be created even if you run the load tester [00:57:19] madhuvishy: try to run it and let's wait 3 mins [00:57:33] madhuvishy: after we will remove the blacklist and re-start [00:59:58] madhuvishy: let me know when you have run your scripts [01:00:01] nuria: [01:00:04] yes [01:00:05] it got created [01:00:08] whatttt [01:00:11] Analytics_13317883 is backkk [01:00:13] ha ha ha ha [01:00:21] now its a new problem [01:00:40] madhuvishy: GOOD JOB Finding that bug [01:00:46] jajaja [01:01:03] apart from Donald Trump leading republican new hampshire primaries [01:01:21] nuria: ha ha [01:01:35] i'm going to try to revise some other schema that is not blacklisted [01:02:01] i ay ay [01:03:16] madhuvishy: ya, ok, i think autoincrement changes are fine [01:03:26] nuria: yup i think so too [01:03:42] madhuvishy: but do test with one schema that is not on blacklist [01:03:47] madhuvishy: feel free to drop tables [01:03:55] madhuvishy: that is why we have beta [01:04:18] nuria: yup I think I tested that with SendBeaconReliability [01:04:20] it's fine [01:04:52] madhuvishy: k, just file a ticket for the blacklist.. do a new batch of events go on.. i wonder if it is only table creation [01:05:04] madhuvishy: we have 1281 on table [01:05:09] madhuvishy: can you run script again? [01:05:24] nuria: sent some more [01:05:30] it does go [01:05:45] so much for that blacklisting. [01:05:48] he he [01:05:55] the regex is off [01:05:56] it works for new revisions but not old? [01:05:59] makes no sense [01:06:05] ya i'll file a bug [01:06:10] madhuvishy: well... i think taht is another problem [01:06:25] let me change config [01:06:30] i think is teh "^" [01:07:43] madhuvishy: try again [01:07:47] i just dropped table [01:08:15] madhuvishy: and changed regex [01:08:23] nuria: okay i sent some events [01:08:39] and there's the table [01:09:07] nuria: i wonder if it's cached somewhere - something is offf [01:09:37] madhuvishy: all right.. there goes my theory [01:09:45] madhuvishy: let's file a bug for this one [01:09:50] nuria: yup [01:10:07] madhuvishy: and when you are done testing autoincrement we can deploy to prod (tomorrow) [01:10:19] nuria: i think it's good [01:11:38] madhuvishy: k, let's deploy tomorrow, write to SAL etc [01:11:46] madhuvishy: and coordinate with jaime [01:12:26] nuria: cool. also i see the git remote for /srv/deployment/eventlogging in beta is http://deployment-bastion.eqiad.wmflabs/eventlogging/eventlogging/.git [01:12:36] is there a method to deploy to beta? [01:13:22] madhuvishy: one that works? ... jaja, no. i have always had to pull [01:13:35] madhuvishy: since teh dawn of the times [01:13:38] nuria: ahhokay [01:29:25] Analytics, Analytics-EventLogging: Some blacklist matching schemas are being consumed by Eventlogging {oryx} - https://phabricator.wikimedia.org/T126410#2013814 (madhuvishy) NEW [01:30:27] Analytics: Prepare for lightning talk on Last access uniques - https://phabricator.wikimedia.org/T126411#2013821 (madhuvishy) NEW a:madhuvishy [05:03:42] Analytics-Wikistats, operations, Regression: [Regression] stats.wikipedia.org redirect no longer works ("Domain not served here") - https://phabricator.wikimedia.org/T126281#2014030 (Peachey88) Is the redirected used all that much? Perhaps someone from #operations could have a look at the stats for it. [08:28:49] o/ [08:49:28] Analytics, ContentTranslation-Analytics, MediaWiki-extensions-ContentTranslation, operations, and 4 others: schedule a daily run of ContentTranslation analytics scripts - https://phabricator.wikimedia.org/T122479#2014195 (Arrbee) Open>Resolved [08:51:16] (PS1) DCausse: Ensure that the schema_repo git submodules are available before packaging [analytics/refinery/source] - https://gerrit.wikimedia.org/r/269627 [09:19:20] Hi elukey :) [09:38:00] dcausse: good morning ! [09:38:04] dcausse: you here? [09:49:35] joal: hi! [09:49:52] Hey dcausse : just sent an email [09:50:09] dcausse: Wanted to let you know that everything is fine on camus this morning [09:50:31] joal: thanks! [09:50:40] np dcausse :) [09:50:47] sorry for the mess yesterday [09:56:20] joal: hey np, it happens. it's our fault because we should monitor this data more carefully [09:57:04] dcausse: shared error (I had a bad feeling while deploying with ottomata about changing jars that don't actually change) [09:57:27] dcausse: I'll add that to my today's discussion sheet :) [09:57:34] :) [10:05:19] (PS1) Joal: Correct bug in last_access_uniques jobs [analytics/refinery] - https://gerrit.wikimedia.org/r/269645 [10:55:43] Analytics-Kanban: Add the possibility to introduce new email templates to Burrow - https://phabricator.wikimedia.org/T126008#2014419 (elukey) Change has been merged! [10:55:53] Analytics-Kanban: Add the possibility to introduce new email templates to Burrow - https://phabricator.wikimedia.org/T126008#2014420 (elukey) Open>Resolved [10:56:31] Analytics-Tech-community-metrics: Korma: Incorrect ticket count on top contributors page - https://phabricator.wikimedia.org/T126328#2014421 (He7d3r) and now it shows only 7 tickets: | Rank | Name | IRC | MW Rev | Tickets | Source Rev | ML | ----- | ----- | ----- | ----- | ----- | ----- | ----- | 38 |... [11:55:17] (CR) DCausse: "Well.. in fact the exec plugin that runs git submodule update is mandatory, the release plugin will clone a fresh repo from the tag when b" [analytics/refinery/source] - https://gerrit.wikimedia.org/r/269627 (owner: DCausse) [13:31:48] Analytics-Tech-community-metrics: Korma: Incorrect ticket count on top contributors page - https://phabricator.wikimedia.org/T126328#2014709 (Aklapper) Open>Invalid a:Aklapper The algorithm takes contributor **positions** (emphasis by me) in each data source activity. It is a rank not a number of ti... [14:13:41] Analytics-Tech-community-metrics: Korma: Incorrect ticket count on top contributors page - https://phabricator.wikimedia.org/T126328#2014788 (He7d3r) Oh, cool! I must have read that description too fast and incorrectly... Maybe it would be helpful to add a tooltip to the numbers, as in "This contributor is r... [14:15:22] Is it expected that only the top 10 users are ranked for participation on mailling lists? [14:15:22] http://korma.wmflabs.org/browser/top-contributors.html [14:15:41] (for the others the page shows a "-" instead of a rank) [14:16:52] What is the difference between the columns "Mediawiki Reviews" and "Source code review"? [14:55:06] joal, mforns: any idea --^ [14:55:18] I am a bit ignorant on the subject :) [14:58:47] no idea elukey [15:00:11] I'm completely ignorant on the subject :) [15:02:18] Helder: woud you mind to wait for US people to come online? They will surely have a better understanding [15:08:57] I'll probably be here [15:28:08] joal / elukey (not pinging otto 'cause he's sleeping): I was wondering what you thought about backfilling pageviews back to May 2015: http://dumps.wikimedia.org/other/pageviews/ [15:28:23] right now we only have projectviews back past October [15:29:05] it would be quite a bit of work, because the files are hourly. I'm thinking we could do it in Erik Zacthe's compressed format and those would be daily [15:29:35] milimetric: no idea about the work to do sorry :( [15:29:44] milimetric: If we do it with oozie and parallelize nicely (not too much), should be ok to have it with current format [15:29:53] elukey: no sok, I can explain [15:30:17] elukey: so all these jobs are done, they just got started with a start date of October so we don't overload the cluster [15:30:24] It would take some time to get done, but would certainly get done :) [15:30:33] so I'm just asking for capacity and Jo seems to think we have it [15:31:04] milimetric: On the look run we have capacity, it's just the matter of not being bursty :) [15:31:09] elukey: here's the job and its start: https://github.com/wikimedia/analytics-refinery/blob/master/oozie/pageview/hourly/coordinator.properties#L36 [15:31:12] uh... that says May :) [15:31:14] wait a minute [15:31:24] k, makes sense [15:31:29] yeah, so we have to make sure we launch it nicely [15:31:44] milimetric: We still would have to make a dedicated job to only dump pageviews, not recompute them [15:32:25] cause for the moment the job extracts pageviews from webrequest and then dump them - we only would keep the dump part of it on existing extracted data [15:32:50] mmm, right, so a trimmed workflow and a new coordinator [15:32:59] yessir [15:33:02] I can do that, that's fine [15:33:21] thx, good to know about capacity if we take care to not burst [15:33:22] milimetric: Don't bother too much -- It would be a run-and-garbage code [15:33:29] yeah, 'course [15:33:49] milimetric: it also depends on the complexity of the runs and the size of the data, obviously :) [15:34:35] milimetric, joal: if it is not too urgent I'd like to do the work [15:35:04] it's not urgent, no, and I can show you how I do it, maybe I can learn it better in the process [15:35:07] elukey, milimetric : Can I let you prepare that, and possibly review before launch ? [15:35:07] I'll file a task [15:35:19] it would be interesting to know 1) how to build a oozie job, 2) how to check the cluster's capacity [15:35:25] super :) [15:36:13] atm I still need to reimage 16 servers with jessie for ops, so I'll probably get to it on Friday/next week [15:36:29] joal: are you happy that I'll bother you a lot during the next days? :P [15:36:32] kidding :) [15:36:56] elukey: I'm off for end-of-wee, so you can try :-P [15:37:07] milimetric: would you mind to check Helder's questions posted before? [15:37:15] ahhhhh [15:38:38] a-team, need to go and grab Lino from the creche [15:38:47] Will see you when he's asleep [15:41:16] Analytics: Back-fill pageviews data for dumps.wikimedia.org to May 2015 - https://phabricator.wikimedia.org/T126464#2015119 (Milimetric) NEW a:elukey [15:41:41] \o/ [15:41:47] :) [15:42:30] so you can bother me with building an oozie job but I'm not super sure how to check on the cluster health, I'd just stumble through the docs on wikitech [15:42:42] I'm *awesome* at building an oozie job [15:43:04] [15:43:21] :) [15:53:52] milimetric, yt? [15:53:58] yes, hi :) [15:54:18] hey! do you have 10 mins to troubleshoot d3 with me? [15:54:38] I'm facing a poltergeist bug [15:55:38] to the batcave! [15:55:41] :] [16:00:21] milimetric, I lost you [16:06:42] mforns: nuria's not around yet, so we can keep chatting if you want [16:06:52] milimetric, ok [16:06:56] batcave? [16:07:01] yep [16:18:52] dcausse: hihiii [16:18:53] morning [16:18:59] well, late morning for meeee :) [16:29:20] ottomata: o/ [16:30:54] hiyaa [16:32:07] ottomata: hi! [16:32:52] dcausse: ok, i think we ahve standup starting now buuUuuut [16:32:56] things mostly looking good [16:33:07] its a little messy, so and i'm worried about data in a couple of hours on feb 3 [16:33:17] but, most of the data from last week is all coming back now [16:33:29] overnight i imported to my home dir [16:33:39] am now moving it back in place, and then letting the normal camus do its thing [16:38:25] Analytics-Kanban, Patch-For-Review: camus-wediawiki job should run in production (or essential?) queue {hawk} [1 pts] - https://phabricator.wikimedia.org/T125967#2015242 (Milimetric) a:JAllemandou [16:48:16] mforns: oops, we should've stayed :) [16:48:20] dcausse: ok [16:48:24] but maybe just push the code so I can start checking it out too [16:48:32] milimetric, hehehe, omw [16:48:35] I'm gonna grab lunch soon, but I'll look at it [16:49:00] hmmm, ok yeah, i am missing data from hours 14 and 15 on feb 3 [16:49:14] earliest ts in kafka is Wed Feb 3 13:26:24 UTC 2016 !!! [16:49:15] hahah [16:49:16] ah! [16:49:20] i have 30 mins to save this data..... [16:49:21] ON IT [16:51:56] (PS1) Mforns: Add hierarchy visualization [analytics/dashiki] - https://gerrit.wikimedia.org/r/269713 (https://phabricator.wikimedia.org/T124296) [16:52:41] (PS2) Mforns: Add hierarchy visualization [analytics/dashiki] - https://gerrit.wikimedia.org/r/269713 (https://phabricator.wikimedia.org/T124296) [16:53:23] haha (not true about 30 mins...actually i think kafka could delete this data at any time :/) [16:53:25] importing now [17:04:16] i remember something about eventlogging data being available in hive, but not finding it. Where could i find it? Looking to do some heavier analytics/session reconstruction/etc on the data we collect about search [17:05:11] https://wikitech.wikimedia.org/wiki/Analytics/EventLogging#Access_data_in_Hadoop [17:05:12] ebernhardson: ^ [17:05:25] ahha, i should have looked harder in wikitech :) [17:05:32] :) [17:05:36] i find it easier to access in spark [17:05:41] since you don't need to create a table first [17:05:41] ottomata: sorry was in meeting [17:06:04] ottomata: yea i think spark will actually be easier for session reconstruction and whatnot as well [17:07:04] dcausse: oh, whoa [17:07:09] just read your comment on that patch [17:07:17] so mvn release + submodules don't work eh? [17:07:36] ottomata: yes.. it was not really your fault, even with a proper git submodules update the build would have been broken anyways [17:07:56] huh, how did we release 0.0.23 with them there??? [17:07:58] yes mvn release:perform will checkout a fresh repo [17:08:10] it was not a git submodule at that time [17:08:16] ahhh [17:08:18] hm [17:08:31] ok, i think we need a task to figure out a better way to share these schemas! [17:08:38] we kinda want that for eventbus too, but maybe that is a separate task [17:08:38] hm [17:08:39] best of both world maven release and git submodule :) [17:09:17] dcausse: do the schemas have to be present at build time? [17:09:30] could we make it take a local dir path, and it'd just look them up at run time? [17:09:52] ottomata: I think it would be way better to not have them in the jar yes [17:10:07] yeah, and we can easily deploy event-schemas on its own [17:10:08] and the build does not care about specific schemas [17:10:12] aye [17:10:27] it would only if you were actually using specific class bindings in your code for it [17:10:35] and it would allow to do schema upgrade without builder refinery-camus [17:10:39] ja [17:11:00] ottomata: no we don't use class bindings, only generic stuff [17:11:03] aye [17:12:30] so, in thory we could deploy the event schemas to hdfs, or maybe just to analyitcs machines via trebuchet? [17:15:34] ja for sure [17:25:59] (CR) Ottomata: [C: 2 V: 2] Correct bug in last_access_uniques jobs [analytics/refinery] - https://gerrit.wikimedia.org/r/269645 (owner: Joal) [17:27:34] sp dcausse should I even merge that refinery pom change? [17:27:45] or, should we just create a ticket to fix this? [17:30:36] (CR) Ottomata: "Do we still need this? Should we abandon?" [analytics/camus] - https://gerrit.wikimedia.org/r/242907 (owner: Nuria) [17:32:55] ottomata: I don't know... it depends if you plan to make future release ? [17:33:20] if a release is needed like a hotfix we should merge it before [17:34:14] hmm, but i thought it won't work anyway? [17:36:11] my patch? [17:36:51] maybe I was not clear, without the pom.xml patch all releases will be broken [17:37:52] oh, i thought you were saying that mvn release wouldn't work even with your patch [17:38:24] no I think it works and is actually needed [17:39:09] oh ok [17:39:10] cool [17:39:11] merging then [17:39:20] thanks much for that [17:39:28] (CR) Ottomata: [C: 2 V: 2] Ensure that the schema_repo git submodules are available before packaging [analytics/refinery/source] - https://gerrit.wikimedia.org/r/269627 (owner: DCausse) [17:40:00] ottomata: thanks, I'll cleanup everything when we move these schemas out of the jar [17:42:29] ok cool [17:57:15] (PS3) Milimetric: [WIP] Add hierarchy visualization [analytics/dashiki] - https://gerrit.wikimedia.org/r/269713 (https://phabricator.wikimedia.org/T124296) (owner: Mforns) [18:07:51] logging off a-team! talk with you tomorrow! [18:08:25] elukey: night! [18:08:30] laters! [18:08:31] later Luca, have a nice night :) [18:09:41] Hi ottomata, quick heads up on camus for media-wiki [18:10:10] I looked into camus this morning, it looked fine, so I assumed everything was back in place - Sorry for the false joy dcausse :( [18:10:19] its all cool now! :) [18:10:33] Thanks for having triple checked ! [18:10:37] yes all data is here just need to run oozie [18:11:03] right dcausse ... It's a pain, but should work [18:14:43] ottomata: You've had to re-import everything using a fresh camus for mediawiki ? [18:15:36] joal: batcave real quick? [18:15:40] sure ottomata [18:31:14] oop, sorry joal! [18:31:22] were you just saying sometihng? [18:38:16] nah, nothing ottomata :) [18:38:40] k laters, heading to cafe...back in a bit [18:42:59] madhuvishy: mobrovac was interested in your dockerization of wikimetrics, because they have dockerized some mediawiki stuff as well [18:43:15] talk amongst yourselves :) [18:43:24] milimetric: ah yes we chatted about it a little bit at docker meetup yesterday :) [18:43:24] yup, madhuvishy mentioned it yesterday at the docker meet-up :) [18:43:30] haha [18:43:33] :D [18:43:40] ah cool [18:44:31] madhuvishy: https://github.com/wikimedia/mediawiki-containers [18:44:34] mobrovac: I wrote a little bit here - https://github.com/wikimedia/analytics-wikimetrics#development-environment - the compose file and Dockerfile are in the root too [18:44:44] gr8 [18:44:45] thnx [18:44:57] mobrovac: cool thanks :) [18:45:12] maybe we could integrate the two [18:45:56] mobrovac: wikimetrics doesn't need mediawiki though [18:46:12] true [18:46:27] it's just a flask app with celery/redis and mysql [19:03:53] halfak: Hello o/ [19:04:30] o/ joal [19:04:41] you looked for me yesterday [19:05:20] Oh! Yeah. It was regarding the location of the jar file we needed on the IA cluster [19:05:23] But we found it :) [19:05:33] Horray for old etherpads :) [19:05:33] Arf :) [19:05:40] For sure ! [19:05:51] script is working ? [19:06:06] Not quite yet. Last I left it in schana's hands. [19:06:16] Mwarf :( [19:06:29] We were having trouble getting subprocess to pass arguments to your java stuff in ways that it understands. [19:06:32] Weirdly enough. [19:06:41] Weird indeed ! [19:07:07] Do you know if your script should handle something like: --timeout '500'? [19:07:07] I have a branch that I switched over to argparse (for type safety stuff), but haven't tested it yet [19:07:25] Wait. python argparse? [19:07:30]