[01:29:44] TimStarling: I added getMemoryUsage() and getCPUUsage() to the LuaInterpreter abstract class and added stub implementations for LuaStandaloneInterpreter in https://gerrit.wikimedia.org/r/#/c/249337/ , and then updated the logging patch (https://gerrit.wikimedia.org/r/#/c/248657/) to use that and the PSquare implementation from https://gerrit.wikimedia.org/r/#/c/249025/. Tested it on mw1017 and it did the right things. [15:39:12] AaronSchulz: 333 Undefined index: timeout in /srv/mediawiki/php-1.27.0-wmf.4/includes/objectcache/MemcachedPeclBagOStuff.php on line 84 [16:11:19] bd808: (assuming you know these types of things) Are the metrics behind https://grafana.wikimedia.org/dashboard/db/authentication-metrics coming from elasticsearch? Or is that eventlogging? [16:11:53] direct to graphite via monolog [16:12:04] so neither really [16:12:32] ummm why is that broken? [16:12:35] Can graphite do any alerting? Like if we get a spike of failures? [16:12:53] nope. we need to build yet another thing for that [16:13:11] we do have the ability to set monitors in icinga via puppet rules [16:13:13] Dashboard is cool, I'm just wondering how to get notified if something goes sideways. I was hoping I could point elastalert at elastic... [16:17:16] csteipp: We can do icinga alerts like this -- https://gerrit.wikimedia.org/r/#/c/233071/3/manifests/role/graphite.pp,unified [16:17:51] I didn't have good luck trying to use holt-winters predictions, but I may have just set things up wrong [16:18:51] I want to start playing with detection systems based on graphite. There are several in the wild including one from etsy that at lest looks promissing [16:19:07] * bd808 makes a note to actually talk to ori about these things [16:23:55] bd808: I just saw https://github.com/composer/composer/pull/4542, yay :D [16:24:31] totally! I was expecting a debate and they just merged it :) [16:26:08] should we try and get 1.3.0 into the 1.26 release? [16:26:58] that would be nice [16:34:47] make sure to fill a task about it [16:34:58] and tag it with mw-1.26-release :-D [17:39:43] legoktm: how often is that 'timeout' error happening? Any idea why? [17:39:53] * legoktm looks [17:41:13] AaronSchulz: ~15/sec according to hhvm.log [17:41:55] does is_subclass_of() not work or something? [17:43:40] on mw1017: [17:43:40] > var_dump(is_subclass_of('MemcachedPeclBagOStuff', 'MemcachedBagOStuff')); [17:43:40] bool(true) [17:46:55] AaronSchulz: I think it might be because of the MultiWriteBagOStuff changes to use objectfactory? [17:49:07] makes sense [17:49:34] we can change the spec to use a 'factory' one using getInstance( 'memcached-pecl' ) [17:49:52] that would also avoid having duplicated objects in php memory [17:51:14] making a patch [19:18:04] anomie: any chance you could review https://gerrit.wikimedia.org/r/#/c/249337/ ? [20:09:44] anomie: i fixed the spacing issue -- would you be up for merging it? [20:55:37] could someone review a trival fix for a UBN in wmf.4 in RecentChanges? https://gerrit.wikimedia.org/r/#/c/249502/ [20:58:12] (reviewd, thanks) [22:07:17] TimStarling: https://gerrit.wikimedia.org/r/#/c/249337/ , https://gerrit.wikimedia.org/r/#/c/248657/ , https://gerrit.wikimedia.org/r/#/c/249025/ :) Updated after your comments. I also added a small, real-world data set with a power law distribution to the PSquare unit tests to confirm sufficient accuracy. [22:11:28] bd808: I ran into a fun merge-plugin issue just now. [22:11:42] yeah? [22:12:06] bd808: I was including SyntaxHighlight_GeSHi's composer.json through the plugin. Someone recently added mw/cs 0.5.0 as a dev dependency. But core is still on 0.4.0, so composer refuses to do anything until I removed one of them [22:12:33] that's the right behavior [22:12:48] although we should make it so you can pick and choose what to merge [22:12:59] like not doing require-dev [22:13:14] open a ticket and I'll do that :) [22:14:06] Using absolute version numbers for things in dev-require actually bugs me [22:14:23] we have to for mw-cs though [22:14:25] (me too) [22:14:40] otherwise stuff would start randomly failing whenever we released a new version [22:14:43] you only have to because you are breaking semver [22:14:51] or abusing it [22:15:11] and if a new rule is a rule then shouldn't it break the tests? [22:15:54] we're following semver technically because we haven't hit 1.0.0 yet [22:16:02] I get why we are pinning dependent libs since we can't commit composer.lock [22:16:25] it breaks tests because when the new rule is added, if you have code that doesn't pass, it'll fail [22:16:35] right... [22:17:04] but if the sniffer has been changed then the code should change should it not? [22:17:37] er, I'm not understanding what you mean. which code is "the code" here? [22:17:39] unless you are saying that mw-cs is just a suggestion [22:18:07] all code attempting to assert compliance with mw-cs [22:18:23] maybe the problem here is that you are evolving a standard [22:18:31] and I guess that is legit [22:18:35] Yes, the standard is incomplete [22:19:32] the problem is IMO that mw-cs is both a standard and a software to check against a standard [22:19:56] for the software it is reasonable to say that gaining new functionality is backwards compatible [22:20:11] for the standard, not so much [22:21:01] as long as you are pinning the major version, tests should not start breaking from a composer update [22:22:19] I wonder if it would make more sense to implement the rules in mw-cs but require them to be declared in the phpcs.xml file [22:22:58] mw-cs contains a ruleset with all the upstream rules that we use as well as the custom rules we've written [22:23:28] it would be inconvenient to copy it over to all repos manually [22:27:03] maybe mw-cs should provide a bunch of phpcs.xml files - mw-.xml - and then you could just refer to the right one from the software under test [22:28:43] That doesn't really seem like an improvement to me. [22:29:19] The problem with composer-merge-plugin in this case is that "require" dependencies are supposed to be used by MediaWiki in the central vendor, and "require-dev" is for the developer to run in that repository - mw shouldn't see them [22:29:29] yeah [22:29:31] so bd808's proposed solution of allowing require-dev to not be merged makes sense [22:29:47] like I said we should add a config setting for that [22:30:58] * bd808 is hip deep in stability flag nonsense [22:31:21] the new patch I did is *almost* right but not quite [22:31:34] it's much better than what we had before at least [22:31:56] I was referring to the problem of having to pin exact versions in composer.json, you could just decouple the standards version from the library version (and thus from composer) [22:32:09] *nod* [22:54:24] filed as https://github.com/wikimedia/composer-merge-plugin/issues/85