[01:18:48] (PS1) Madhuvishy: Add script to update refinery source jars from jenkins [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290617 [01:19:39] (CR) Madhuvishy: [C: 2 V: 2] "Self merging - not to the master branch" [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290617 (owner: Madhuvishy) [02:25:08] (PS1) Madhuvishy: Change jar update script permissions to executable [analytics/refinery] - https://gerrit.wikimedia.org/r/290621 [02:25:34] (Abandoned) Madhuvishy: Change jar update script permissions to executable [analytics/refinery] - https://gerrit.wikimedia.org/r/290621 (owner: Madhuvishy) [02:27:15] (PS1) Madhuvishy: Change jar update script permissions to executable [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290622 [02:27:42] (CR) Madhuvishy: [C: 2 V: 2] "Self merging - this is not branch master" [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290622 (owner: Madhuvishy) [02:36:25] (PS1) Madhuvishy: Modify update jars script to make the commit and git review [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290623 [02:36:59] (CR) Madhuvishy: [C: 2 V: 2] "Self merging - this is not the master branch" [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290623 (owner: Madhuvishy) [02:44:24] (PS1) Madhuvishy: Change git review to git push [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290624 [02:44:51] (CR) Madhuvishy: [C: 2 V: 2] "Self merging - this is not master" [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290624 (owner: Madhuvishy) [05:08:55] (PS1) Madhuvishy: Add git hook to append change ids to commit msgs [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290629 [05:12:57] (CR) Madhuvishy: [C: 2 V: 2] "Self merging, not to master" [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290629 (owner: Madhuvishy) [05:23:03] (PS1) Maven-release-user: Add refinery-source jars for v0.0.26 to artifacts [analytics/refinery] (jenkins-test) - https://gerrit.wikimedia.org/r/290630 [06:26:02] (PS1) Madhuvishy: Add script for jenkins to commit latest source jars to artifacts [analytics/refinery] - https://gerrit.wikimedia.org/r/290639 [06:27:12] (PS2) Madhuvishy: Add script for jenkins to commit latest source jars to artifacts [analytics/refinery] - https://gerrit.wikimedia.org/r/290639 (https://phabricator.wikimedia.org/T130123) [06:27:48] Analytics-Kanban, Patch-For-Review: Get jenkins to update refinery with deploy of new jars {hawk} - https://phabricator.wikimedia.org/T130123#2325424 (madhuvishy) [06:33:45] Analytics-Kanban, Patch-For-Review: Get jenkins to update refinery with deploy of new jars {hawk} - https://phabricator.wikimedia.org/T130123#2325437 (madhuvishy) a:madhuvishy [08:29:53] elukey: o/ [08:30:44] hello! [08:31:00] quick talk around aqs compaction? [08:31:21] maybe in 15 mins? [08:31:41] sure, ping me when ready [08:37:12] joal: in the meantime https://gerrit.wikimedia.org/r/#/c/290643/2 [08:37:43] the idea would be to set dynamic execution enabled by default, and to fail only in case the standalone options are set [08:38:24] so by default in spark-defaults.conf you get spark.dynamicAllocation.enabled and spark.shuffle.service.enabled set to true [08:40:04] even if we might set it to false by default and then explicitly enable it in our roles [08:40:16] I am sure that Andrew will ask me to do it [08:40:29] now that I think more about it [08:40:30] ahahhaah [08:42:11] mmm but then we'd need the role for spark [08:42:15] only for that option [08:44:25] no probably not, but extra config [08:44:51] https://puppet-compiler.wmflabs.org/2900/analytics1032.eqiad.wmnet/ looks good [08:47:12] posted my comments, will ask to Andrew this afternoon what is the best way forward [08:47:38] going to grab a coffee [09:02:36] joal: going to finish debugging a memcached metric issue, will be back in 30 mins [09:02:42] ok [09:03:12] what do you think about the spark settings? [09:05:03] elukey: Sounds good to me except for the timeout setting for caching executors (not present, is it? [09:06:48] elukey: about the puppet way of doing things, I'm so bad in puppet I don't even think of having an opinion : [09:07:48] ahhh you mean spark.dynamicAllocation.cachedExecutorIdleTimeout [09:07:57] correct sir [09:08:18] got fooled by spark.dynamicAllocation.executorIdleTimeout that is 60s [09:08:22] adding it thanks! [09:08:25] we said the other timeout was good (standard idleEecutor), but we don't want infinity for that one [09:08:38] np elukey, thanks for doing it ! [09:09:00] elukey: I think we want 1h for the spark.dynamicAllocation.cachedExecutorIdleTimeout [09:15:31] joal: https://gerrit.wikimedia.org/r/#/c/290643/3/templates/spark/spark-defaults.conf.erb [09:16:39] oh yes elukey, another (less important) thing that would be great [09:17:00] elukey: Can we silent spark log in shells about losing executors? [09:17:37] elukey: In dynamic allocation mode, losing executors is normal behavior, so we shouldn't log error messages [09:17:51] this requires a "mmmmmmmm" [09:18:02] elukey: at least one, for sure ;) [09:18:50] joal: have you already an idea about the logging setting by any chance? [09:19:09] elukey: not really, looking as well [09:20:43] To specify a different configuration directory other than the default “SPARK_HOME/conf”, you can set SPARK_CONF_DIR. Spark will use the the configuration files (spark-defaults.conf, spark-env.sh, log4j.properties, etc) from this directory. [09:21:02] so I guess that it is just a matter of adding log4j.properties ? [09:21:26] elukey: https://issues.apache.org/jira/browse/SPARK-4134 [09:21:36] file { "${config_directory}/log4j.properties": [09:21:36] source => 'puppet:///modules/cdh/spark/log4j.properties', [09:21:36] } [09:22:01] elukey: Let's wait for an upgrade to 1.6 ;) [09:23:59] joal: we already have a custom log4j file, if you give me the config to shut of those errors I can add it easily [09:24:07] shut off [09:24:31] elukey: makes sense, but I think it's not really a good idea: in some cases (when not in dynamic allocation), those errors are real errors [09:24:51] ahhh okok [09:25:04] so we need a cdh upgrade :D [09:25:05] elukey: I should have thought of that before asking you ... sorry :S [09:25:25] nono good to know, explored a bit the cdh module :) [09:25:27] elukey: indeed, but I think CDH doesn't have a new release, do they ? [09:25:37] not that I know.. [09:25:45] right, so we'll wait a bit :) [09:25:50] no bother thought [09:26:32] 5.7.0 [09:26:37] http://www.cloudera.com/downloads/cdh/5-7-0.html [09:27:54] Wow, elukey, this 5.7 release gives HoS (Hive on Spark) ... I think I want to test that :) [09:28:04] ahhahaahah [09:28:21] + spark rebased on 1.6 --> Good call [09:28:36] Let's discuss that with Andrew when he comes online :) [09:29:27] elukey: cassandra real quick ? [09:29:28] yep! going to finish my work with memcached, then I'll be back! [09:29:31] :P [09:29:34] ok, after then [10:42:55] joal: ganglia and memcached are failing me, sorry :P [10:43:11] ok elukey, doing other things :) [10:43:37] we can chat now or after lunch, as you prefer [10:43:46] elukey: your call ;) [10:43:56] would be better now for me, but ok after if you prtefer [10:46:06] joal: sure let's do it now [10:46:18] ok, batcave ! [11:05:32] joal: I needed to read again leveled compaction, now it makes more sense. thanks for the patience :) [11:06:16] I've read http://www.scylladb.com/kb/compaction/ that pictures it very nicely [11:06:22] how things move from L0 upwards [11:08:52] and non-overlapping ranges among levels [11:10:39] what my brain wanted to know (probably) was how many levels would have "jumped" cassandra for an avg random read [11:11:24] anyhowww, will try to make my ideas clearer [11:12:21] but for the moment it looks much more consistent than DTCS [11:12:31] especially because we are not writing stuff all the times [11:15:50] on aqs1004-a, SSTables in each level: [1, 10, 100, 179, 0, 0, 0, 0, 0] [11:16:30] so with this data, cassandra would need to read MAXIMUM from 4 sstables [11:16:39] (worst case) [11:16:53] given the fact that we have non overlapping ranges of keys in each level [11:17:04] auto-answered [11:17:28] * elukey lunch! [12:44:38] joal: for some reason there was a cassandra process running on aqs1006 that wasn't a cassandra instance [12:45:00] so we were getting [12:45:01] May 25 06:27:56 aqs1006 java[27322]: java.lang.IllegalStateException: Cannot determine instance name of process running as PID 26720 (Hint: missing -Dcassandra.instance-id=?) [12:45:20] of course cassandra-metrics-collector didn't even try to check the other processes [12:45:28] and wasn't pushing metrics :/ [12:45:34] killed the process [12:45:39] May 25 12:43:29 aqs1006 java[21157]: 2016-05-25 12:43:29,126 [DefaultQuartzScheduler_Worker-1] INFO o.w.c.metrics.service.Discover - Found instance aqs1006-a [12:45:42] May 25 12:43:29 aqs1006 java[21157]: 2016-05-25 12:43:29,503 [DefaultQuartzScheduler_Worker-1] INFO o.w.c.metrics.service.Discover - Found instance aqs1006-b [12:46:08] Collection of aqs1006-b complete; Samples written to graphite-in.eqiad.wmnet:2003 [12:46:14] Collection of aqs1006-a complete; Samples written to graphite-in.eqiad.wmnet:2003 [12:46:24] so theoretically metrics should show up in a bit [13:00:16] ah nice, here they are: https://grafana.wikimedia.org/dashboard/db/aqs-cassandra-compaction [13:00:20] joal --^ [13:15:55] Ahhhh :) Thanks elukey ! [13:17:13] I've double checked: aqs1006 have data, so it seems it was a metric only issue [13:17:17] elukey: --^ [13:22:27] yep yep [13:28:14] GOOD MORNNINGGG [13:28:29] Mr ottomata good morning to you ! [13:29:11] elukey: Read the scylladb compaction thing: indeed, very well explained ! [13:32:50] joal: am looking over schema changes one last time [13:32:51] q [13:32:55] https://gerrit.wikimedia.org/r/#/c/288210/7/jsonschema/mediawiki/user_blocks_change/1.yaml [13:33:11] is 'user_id_blocks_changed' a name in the db or mw code, or did we make it up? [13:33:29] ottomata: made up [13:33:59] k, it just sounds really awkward, would something like 'user_id_affected' make more sense? or [13:34:06] maybe it would make sense to call this field just user_id [13:34:08] and the other field [13:34:35] user_id_initiator [13:34:37] or [13:34:37] hm [13:34:37] that's bad [13:34:39] but something like that [13:35:30] ottomata: user_id and user_text as is are used everywhere else as user info for the user making the action, so it makes sense to keep it this way I think [13:35:41] ok [13:35:51] About the naming, I agree it's weird ... But it's the most explicit we have ... [13:36:03] well, this is a user_blocks_change event [13:36:08] I am happy to change it, but don't really know to waht :) [13:36:11] user_id_affected makes sense to me [13:36:24] the user_id that the blocks_change event affects [13:36:36] would work for me [13:36:52] hmm effected? [13:36:53] haha [13:36:57] affected vs effected [13:36:57] huhu [13:36:57] hmmm [13:37:12] time for googling my native language! [13:37:29] huhu: affected seems right ;) [13:37:36] Analytics, Reading-Web-Backlog, Wikipedia-iOS-App-Product-Backlog, Mobile-Content-Service: As an end-user I shouldn't see non-articles in the list of trending articles - https://phabricator.wikimedia.org/T124082#2326276 (Mholloway) [13:37:43] i think affected [13:37:51] ja [13:38:18] k, will update that [13:38:47] Marko had a comment about getting old status as well as new one not feasible... [13:38:56] ottomata: --^ [13:39:10] Any idea who I should contact to get another opinion as well? [13:39:50] o [13:39:51] h [13:39:52] right [13:39:53] hm [13:40:03] ottomata: last question on the affected stuff: Do you want me to change the comment as well, or is it ok as is ? [13:40:32] no comment is fine [13:40:35] the description you mean? [13:40:43] yes [13:40:45] sorru [13:40:54] ja, t hat is fine [13:40:57] k cool [13:41:03] pushing the change ! [13:41:40] joal maybe we can look, have you looked in MW code to find stuff resonsible for blocks changes? is there a hook for it? [13:42:49] ottomata: I NEVER have looked in MW code (I'm too afraid of what I could find) [13:42:52] :P [13:43:08] haha, ok I'll do some quick snorkeling [13:43:13] see what i can see [13:43:49] ottomata: If you find me some places to look at, let's do it together, but I won't be able to help finding the place [13:44:36] joal: found these two hooks [13:44:37] https://www.mediawiki.org/wiki/Manual:Hooks/BlockIp [13:44:43] https://www.mediawiki.org/wiki/Manual:Hooks/BlockIpComplete [13:44:45] that look promising [13:45:02] there is also this [13:45:02] https://www.mediawiki.org/wiki/Manual:Hooks/SpecialBlockModifyFormFields [13:45:03] but i dunno [13:46:04] ottomata: thanks for the review, adding the last changes :) [13:46:05] this is the Block object [13:46:06] https://github.com/wikimedia/mediawiki/blob/master/includes/Block.php [13:46:10] yup! [13:47:27] ahhh joal! [13:47:33] the Blocks object calls the affected user target [13:47:37] so [13:47:37] let's call our fields [13:47:40] user_id_target [13:47:41] ok? [13:47:56] makes sense ottomata :) [13:47:59] Will change again [13:48:00] coo [13:48:55] joal: my mental todo list says you had some questions regarding https://gerrit.wikimedia.org/r/#/c/289594/ ? [13:49:06] joal: this is the block form that actually creates the block [13:49:06] https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialBlock.php [13:49:36] indeed mobrovac, good memory ! [13:50:09] mobrovac: I don't know the scap various stages and their order, so it's difficult for me to have a nopinion on the change :) [13:51:46] basically, there used to be 4 stages, the last of which (promote) restarted the service [13:51:56] euh, s/4/3/ [13:52:17] there are now 4 and promote is not the latest stage, restart_service is [13:52:26] so we want to check the service after the restart, not before [13:52:37] mobrovac: indeed :) [13:52:41] Makes sense [13:52:59] mobrovac: any link on doc on those stages? [13:53:09] euh, dunno frankly [13:53:25] mobrovac: I'll +1 the patch, letting elukey merge it :) [13:53:27] thcipriani sent a mail to wikitech-l and the kind on it [13:53:40] (CR) Joal: [C: 1] Scap: execute checks after the restart_service stage [analytics/aqs/deploy] - https://gerrit.wikimedia.org/r/289594 (https://phabricator.wikimedia.org/T135609) (owner: Mobrovac) [13:54:06] heh joal, elukey said he'll let you inspect and handle it [13:54:21] huhuhu, didn't recall that, I'll merge it then :) [13:54:22] it's not a hot potato! [13:54:42] (CR) Joal: [C: 2 V: 2] Scap: execute checks after the restart_service stage [analytics/aqs/deploy] - https://gerrit.wikimedia.org/r/289594 (https://phabricator.wikimedia.org/T135609) (owner: Mobrovac) [13:55:07] elukey: aqs deploy now or tomorrow morning? [13:55:28] joal: even now is fine for me [13:55:42] elukey: ok let's go [13:55:48] I am DRYng my code review after Andrew's review :P [13:56:00] elukey: you do it or I do it ? [13:58:33] joal: if you have time please go ahead [13:58:40] k [14:00:47] (PS1) Joal: Correct deepStrictEqual assertion function use [analytics/aqs] - https://gerrit.wikimedia.org/r/290688 [14:00:56] elukey: if you don't mind before I deploy --^ [14:05:00] ok joal i think mobrovac is right [14:05:09] you can't know old block settings in the hook at least [14:05:24] there is a moment during form submission when the previous block settings are loaded from the db [14:05:40] we maybe could make another hook there [14:05:46] buut, i dunno [14:05:51] it would be pretty awkward [14:06:20] the problem with putting a hook there is that then that ceases to be an atomic operation [14:06:47] as people could do all kinds of stuff in the hook to abort the process [14:06:56] so i think that'd be a no-go [14:07:26] joal: looks sane to me even if I have no context :) Don't feel bad to auto-merge! [14:07:35] elukey: ok will do [14:07:44] ottomata: https://phabricator.wikimedia.org/T134056#2326297 [14:07:46] \o/ [14:07:54] ah already doing [14:07:56] super [14:07:57] didn't see it [14:08:03] (CR) Joal: "Self-merging bug before deploying." [analytics/aqs] - https://gerrit.wikimedia.org/r/290688 (owner: Joal) [14:08:19] I understand mobrovac [14:08:28] elukey: aye! if you want to you can! i just pinged chris in ops, not doing anything yet [14:08:58] nono don't worry, I think that you need to do the usual dd right? [14:09:09] mobrovac, ottomata: So we'd only have new_blocks instead of old + new (or we could even keep old + new in schema for coherency purpose, and make old not required)? [14:09:42] what would be the point of old_ when we could never fill it? [14:10:01] mobrovac: coherency from a schema perspective [14:10:17] We have other places where we try to follow the old/new pattern (when feasible) [14:11:27] we run the risk of having wrong data this way, so i wouldn't be in favour of that [14:11:36] correctness trumps coherence in my books [14:11:54] yeah, i think i agree with mobrovac, we'd never be able to have old ever [14:12:01] unless we hacked up mw core code, which i doubt we'd get merged :) [14:12:44] mobrovac: just so i understand, you are saying a hook in the middle is bad, because something could fail and then what? [14:12:48] but, that's true already, no? [14:13:20] mobrovac, ottomata: And also, what about revision_visibility_change, same concern ? [14:13:28] there is a hook SpecialBlockModifyFormFields [14:13:46] that gets called after the old blocks are read from the db and merged with the incoming form fields [14:13:52] but before the block is saved [14:14:03] that allows for someone to hook into it and alter the block object before save [14:14:38] (CR) Joal: [C: 2 V: 2] Correct deepStrictEqual assertion function use [analytics/aqs] - https://gerrit.wikimedia.org/r/290688 (owner: Joal) [14:14:47] hmmm [14:14:50] you know [14:14:51] actually [14:14:54] it wouldn't be so bad to add a hook here [14:15:03] here == ? [14:15:07] https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialBlock.php#L256 [14:15:15] s/==/=/ :P [14:15:21] if i am readin gcorrectly [14:15:24] at $block = Block::newFromTarget( $this->target ); [14:15:39] if there was previously a block for target (IP or user) [14:15:44] then $block is what was loaded from db [14:16:02] the code after that is merging what is coming in from the form with what was in the db [14:16:05] and will use that for an update [14:16:12] so, if we added there a [14:16:21] Hooks::run( 'SpecialBlockPreviousFromTarget', array( $this, &$a ) ); [14:16:22] or something [14:16:24] well [14:16:28] Hooks::run( 'SpecialBlockPreviousFromTarget', array( $this, &$block ) ); [14:16:32] something like that [14:16:35] ahhhhh [14:16:35] NO [14:16:38] !log Deploying aqs into aqs_deploy [14:16:41] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [14:16:42] that would just call a hook with the old data [14:17:15] we'd have to add a hook at the bottom of this maybeAlterFormDefaults [14:17:37] we'd need something with both new and old data, and we'd need that at the point where we are 100% sure the transaction's been completed [14:17:44] that passes both $block (old data) and uhhh, $fields? [14:17:56] yeah, that would be the right way to do it [14:18:10] yeah we'd have to save the block in the object for a bit [14:18:19] and pass it to BlockIpComplete [14:18:27] yes [14:18:33] whihc, hm, could be done i guess [14:18:37] that sounds doable [14:18:40] (PS1) Joal: Update aqs to 2d20711 [analytics/aqs/deploy] - https://gerrit.wikimedia.org/r/290693 [14:18:40] hehe [14:19:51] mobrovac: ja who do you think we should bug about this? anomie? [14:20:10] afaik AaronS is the hooks guy [14:20:10] (CR) Joal: [C: 2 V: 2] "Self-merging for deploy." [analytics/aqs/deploy] - https://gerrit.wikimedia.org/r/290693 (owner: Joal) [14:20:16] ah ok [14:20:17] k [14:21:19] i guess aaron is SF time, so pretty early now [14:21:26] all right during the next puppet run the spark configs will be picked up [14:21:35] coool! [14:21:42] awesome elukey, I'll make my pleasure to test that ! [14:21:48] :) [14:23:06] mobrovac: also one thing that have changed a bit in the schemas is https://gerrit.wikimedia.org/r/#/c/288210/8/jsonschema/mediawiki/page_move/1.yaml [14:23:41] mobrovac: Added old and new objects to follow the pattern in other places, and added redirect_title to that [14:24:37] !log deploying aqs from tin [14:24:40] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [14:24:51] elukey: be ready in case I have broken something ;0 [14:25:00] sure [14:27:05] mobrovac, ottomata : I guess we're gonna wait for Aaron opinion, but that'd be awesome if we could have both old and new status :) [14:28:17] * joal has not broken anything !!!! YAY [14:29:56] joal: i will try to look it code up for visibility and page move too [14:30:03] then will post on ticket and solicit for aaron's opinion [14:30:29] ottomata: Thanks a mil for that ! [14:30:42] ottomata: I wouldn't have been able to do the audit you did ... [14:30:56] ottomata: At some point I might ask for some help and explanation :) [14:31:00] sho! [14:31:08] joal: my process was: [14:31:13] google: mediawiki hooks [14:31:25] found this page (hadn't seen it before) https://www.mediawiki.org/wiki/Manual:Hooks [14:31:31] search page for 'block' [14:31:39] then search mw core code for results [14:31:40] :) [14:31:53] then start reading code [14:32:03] (but i guess i have a little bit of previous knowledge about what mw hooks are :) ) [14:32:28] ottomata: That's this last bit on which I'll ask, but later :) [14:32:36] k [14:42:03] ottomata: the disk has been swapped, if you want I can create the partition+fs [14:42:24] hi, do you use git fat w/ archiva.wikimedia.org for deploys? [14:42:47] elukey: go right ahead thank you! [14:42:57] dcausse: yes [14:42:58] we do [14:43:15] ottomata: do you have a way to debug git fat pull when it refuses to find my artifact? [14:43:18] https://github.com/wikimedia/analytics-refinery/tree/master/artifacts [14:43:40] dcausse: i have special powers, so yes :/ i can log into the archiva box and check the shas it has for the artifacts [14:43:41] I checked sha1sum and they are identical but my jar is not resolved :/ [14:43:41] but [14:43:50] dcausse: they are identical in archiav? [14:43:52] or on your local? [14:43:58] I dl from archiva [14:44:00] oh! [14:44:06] then that should match [14:44:12] so the dl from archiva sha matches what git fat says? [14:44:18] yes :/ [14:44:25] ok looking, which jar? [14:44:38] swift-repository-plugin-2.3.3.jar [14:44:56] #$# git-fat 61b7500a331cdf2b9e56779455eb2fa299c19177 14925 [14:45:15] Analytics-Kanban, RESTBase, Services, RESTBase-API, User-mobrovac: Enable rate limiting on pageview api - https://phabricator.wikimedia.org/T135240#2326487 (mobrovac) The reduced limits were deployed earlier today and show warnings when the rate is surpassed globally. [This dashboard](https:/... [14:45:28] hm, dcausse that jar exists in the git fat store with 61b7500a331cdf2b9e56779455eb2fa299c19177 [14:45:31] that look scorrect [14:45:46] ls -l git-fat/61b7500a331cdf2b9e56779455eb2fa299c19177 [14:45:46] lrwxrwxrwx 1 archiva archiva 122 May 25 13:41 git-fat/61b7500a331cdf2b9e56779455eb2fa299c19177 -> ../repositories/releases/org/wikimedia/elasticsearch/swift/swift-repository-plugin/2.3.3/swift-repository-plugin-2.3.3.jar [14:45:59] file exists with that size too [14:45:59] so maybe some sort of caching in the .git folder maybe? [14:46:13] maybe? what is the error you are getting? [14:46:35] I see no error [14:46:46] oh, its just not dling the actual file? [14:46:48] git fat pull [14:46:48] ? [14:46:50] does nothing? [14:46:55] yes [14:47:12] dcausse: do you have this working for other jars? [14:47:38] yes [14:48:05] well not all jars are in archiva yet, maybe it bails out when it encounter too many errors? [14:48:18] hm, maybe? [14:48:21] but some are dled? [14:48:24] yes [14:48:30] that is strange [14:48:41] ok I'll continue to upload, thanks for checking there [14:48:45] ok [14:48:49] yeah lemme know if you figure anything out [14:48:55] sure, thanks! [15:30:21] Analytics-Kanban, EventBus, Patch-For-Review: Propose evolution of Mediawiki EventBus schemas to match needed data for Analytics need - https://phabricator.wikimedia.org/T134502#2326641 (Ottomata) 3 schemas being altered in https://gerrit.wikimedia.org/r/#/c/288210 require knowledge of the previous s... [15:30:34] joal: ^ https://phabricator.wikimedia.org/T134502#2326641 [15:31:43] Wow ottomata ! Thanks mate :) [15:32:17] mobrovac: look that comment over and see if it makes sense to you [15:32:21] i'll try to ping aaron later [16:00:59] a-team standup wooo [16:06:18] Analytics-Kanban: Get jenkins to automate releases {hawk} - https://phabricator.wikimedia.org/T130122#2326856 (Nuria) [16:06:20] Analytics-Kanban: Figure out if the Changelog file can be updated in the release process by Jenkins {hawk} - https://phabricator.wikimedia.org/T132181#2326854 (Nuria) Open>declined [16:06:36] Analytics-Kanban: Figure out if the Changelog file can be updated in the release process by Jenkins {hawk} - https://phabricator.wikimedia.org/T132181#2190783 (Nuria) This was not needed as spec-ed out here. [16:08:27] Analytics-Dashiki, Analytics-Kanban, Patch-For-Review: Visualize unique devices data {bear} - https://phabricator.wikimedia.org/T122533#2326896 (Nuria) Open>Resolved [16:08:29] Analytics-Kanban, Patch-For-Review: Make Unique Devices dataset public {mole} - https://phabricator.wikimedia.org/T126767#2326897 (Nuria) [16:08:31] Analytics-Dashiki, Analytics-Kanban, Patch-For-Review: Add support to 'displayName' param in config - https://phabricator.wikimedia.org/T134924#2326900 (Nuria) Open>Resolved [16:08:48] Analytics-Kanban, Patch-For-Review, RESTBase-API: Start date of unique devices counts endpoint is always off by one day - https://phabricator.wikimedia.org/T134840#2326918 (Nuria) Open>Resolved [16:18:19] Analytics: Provide a ua-parser service using the One True Wikimedia UA-Parser™ - https://phabricator.wikimedia.org/T1336#2327013 (Krinkle) [16:20:54] Analytics: Browser report on analytics.wikimedia.org has broken icons - https://phabricator.wikimedia.org/T136217#2327028 (Krinkle) [16:28:18] (PS1) Krinkle: Use HTTPS for wikimedia.org urls [analytics/analytics.wikimedia.org] - https://gerrit.wikimedia.org/r/290711 [16:31:14] Analytics, Wikipedia-iOS-App-Product-Backlog, Mobile-Content-Service: As an end-user I shouldn't see non-articles in the list of trending articles - https://phabricator.wikimedia.org/T124082#2327089 (Jhernandez) [16:31:58] (PS3) Madhuvishy: Add script for jenkins to commit latest source jars to artifacts [analytics/refinery] - https://gerrit.wikimedia.org/r/290639 (https://phabricator.wikimedia.org/T130123) [16:35:42] ottomata: when you get a chance can you add maven-release-user@wikimedia.org to it's own gerrit group - Analytics-ci? and give it push rights here https://gerrit.wikimedia.org/r/#/admin/projects/analytics/refinery,access [16:36:26] (PS1) Krinkle: index.html: Minor HTML clean up [analytics/analytics.wikimedia.org] - https://gerrit.wikimedia.org/r/290712 [16:37:15] (CR) Madhuvishy: "Not sure if we should consolidate the download-refinery-source-jars script and this one, or we can just leave it be even though some code " [analytics/refinery] - https://gerrit.wikimedia.org/r/290639 (https://phabricator.wikimedia.org/T130123) (owner: Madhuvishy) [16:40:48] hehe, madhuvishy waht about to comment that [16:42:03] ottomata: yeah I mean we can remove the other script - this one assumes we will always be in the right workspace because jenkins workspace is going to be refinery root. it will also run the git push. not sure if the other one that displays the command is still useful [16:43:45] (CR) Ottomata: "Cool." [analytics/refinery] - https://gerrit.wikimedia.org/r/290639 (https://phabricator.wikimedia.org/T130123) (owner: Madhuvishy) [16:44:00] madhuvishy: ja i think we should have one script that is smart enough for both use cases, perhaps with some options [16:44:07]