[06:01:38] TimStarling: https://wikitech.wikimedia.org/wiki/Obsolete:Yaseo_migration_plan looks like multi-dc mysql to me ;) [06:03:12] fun [06:04:39] TimStarling: do you remember any of that? How did memcached work? [06:05:20] it's interesting that we tried that in the old days [06:05:22] I don't think we migrated memcached, I think we just let it start up cold [06:05:43] sure but how did you purge stuff? [06:07:43] not sure what you mean [06:08:06] it was not really multi-dc mysql, that is just a description of how we moved from one DC to another [06:08:54] while those wikis were in yaseo, we just served them out of yaseo, there were no cross-DC requests [06:09:31] we sent those wikis to yaseo at the DNS level, and they had their own caches [06:09:48] and there were no shared memcached keys then? [06:10:18] no, I don't think so [06:10:47] what made us switch back to having dbs in one site? [06:10:48] for commons we used thumb.php [06:11:05] I don't think CentralAuth existed [06:11:10] * AaronSchulz always felt bad that we lost the one CDN in asia [06:11:19] *CDN site [06:12:23] yaseo was donated, but after a few years, the servers were getting old and inadequate, and there was no interest in repeating the donation [06:12:37] and the yahoo staff weren't especially communicative, it wasn't a great place to be hosted [06:13:01] so we decommissioned the site [06:13:20] mark made the decision [06:13:21] gtg [06:13:30] ok, see you [16:30:39] greg-g: https://twitter.com/byrichardpowell/status/662637585131511809 [16:34:07] Reedy: neat [17:21:31] AaronSchulz: https://gerrit.wikimedia.org/r/#/c/247020/ (mw-vagarant + jobrunner) [17:23:57] http://i.imgur.com/rqEFbhg.png <--- why do we confuse users with "confirmation code" even when it is not applicable? [17:24:31] good question [17:24:48] generic error message for multiple auth plugins? [17:25:34] i haven't had my coffee yet, no way I'm looking at CentralAuth [17:25:53] at least it doesn't parse html with regex [17:26:02] not may other things good to say about it [17:27:20] I can't find that message in CA [17:27:29] could be a commons override [17:27:39] (i should have mentioned: this was for commons.wm.o) [17:28:39] on enwiki I get "Incorrect password entered. Please try again" [17:29:40] I think it is some random commons change [17:30:13] How can I make uselang=qqx sticky to see where it comes from? [17:30:59] ori: https://commons.wikimedia.org/wiki/MediaWiki:Wrongpassword [17:31:16] yep [17:32:02] do we show Wrongpassword for wrong captcha? [17:32:39] @todo Make these separate messages, since the message is written for both cases [17:32:52] it's used in SpecialChangePassword [17:33:00] horribly [17:33:54] SpecialChangeEmail, SpecialChangePassword and SpecialUserlogin all recycle that message [17:34:05] l10n fail [17:39:29] ori: since you nerd sniped me on that... got time to review a mw-vagrant Advanced Puppet Hack™? -- https://gerrit.wikimedia.org/r/#/c/244821/ [17:40:00] sure, reviewing [17:40:47] heh, robots.d/ [17:41:28] I actually thought about that too [17:41:37] but it would be a nightmare in the same way [17:41:41] how disciplined are we about ensuring that roles clean up after themselves? [17:41:49] not at all [17:42:08] want a clean build than shoot the vm and start over [17:42:15] we do it where it is easy to do [17:42:31] but we don't do ensure=absent stuff [17:42:36] so i would suggest something simpler -- add 'replace => false' to the robots.txt resource and use file_line from stdlib in simple_performant [17:43:08] 'replace => false' means "Whether to replace a file or symlink that already exists on the local system but whose content doesn’t match what the source or content attribute specifies. Setting this to false allows file resources to initialize files without overwriting future changes. " [17:43:44] but Advanced Puppet Hack™! :) [17:43:59] I can look at file_line [17:44:00] it is neat [17:44:06] what's in the simple performant robots.txt? [17:44:13] if it's not too controversial maybe we can just make that the default? [17:45:13] it blocks /w/index.php? and /w/api.php [17:45:31] it's a little bit goofy, no? [17:45:37] i mean, spiders are not going to crawl your vagrant instance [17:46:11] i saw we just delete it from simple_performant [17:46:19] simple_perfomant is mostly for people who are crazy and using mw-vagrant to try and run a public MW [17:46:29] people actually do that? [17:46:53] it has been done [17:47:07] that role came from someone who was doing just that [17:47:07] replace => false & file_line then [17:47:24] the labs robots.txt is Disallow: / [17:47:35] we could make that the default for vagrant as well [17:47:40] that would also eliminate conflicts [17:47:40] which actually seems like the right mw-vagrant default [17:47:43] yeah [17:47:44] +1 [17:47:57] then the simple performant one is redundant [17:48:16] So just disallow: / and then let the user hack it if they want to [17:48:19] that works for me [17:48:45] but my 31337 puppet skillz won't be on display :) [17:50:04] plenty of other opportunities [17:50:13] your patch is kind of cool btw [17:50:16] i did not know you could do that [17:53:51] I didn't either until I figured it out for this problem. [17:54:15] maybe I'll write a blog post nobody ever reads about it [18:24:15] ori: now with 100% less trickery -- https://gerrit.wikimedia.org/r/#/c/244821/ [19:01:17] wow, is this accurate? https://integration.wikimedia.org/cover/mediawiki-core/master/php/ [19:04:00] yes [19:05:14] Is that including all of the Messages classes [19:05:30] ? [19:05:59] urandom: not so loud [19:32:54] anomie: [[:mw:API:Main_page]] says "On Wikimedia wikis, if you don't supply a User-Agent header, or you supply an empty or generic one, your request will fail with an HTTP 403 error" [19:33:12] but 8% of the traffic I can see in the logs has an empty UA [19:33:19] do we not really require it? [19:33:49] bd808: That used to be true, but ops dropped that when they changed from squid to varnish. We currently reserve the right to reimplement it, but chances are we won't. [19:34:08] (sarcastic "we") [19:34:21] ah. so it was blocked at the Varnish level and not in MW code [19:34:25] There was a discussion about this recently... [19:34:41] yeah I remember domas saying something about it [19:35:20] the UA data for api.php requests is full of aweful [19:35:24] [Wikitech-l] What happened to our user agent requirements? [19:35:32] September 2015 [19:36:09] urandom: sadly yes [19:38:15] urandom: and most of those unit tests aren't 'real' unit tests to begin with :/ [19:38:27] (ie: they need a db spun up to run) [19:38:38] most are horribly slow integration tests [19:38:47] s/most/at least some/ # I don't know a percentage [19:39:23] well, enough that the default test class sets up and tears down as though a live DB is needed [19:39:26] see also: why the mwcore-zend job takes for effing ever in CI [19:39:38] 20 minutes or so these days :( [19:40:51] legoktm: thanks for pointing that thread out [19:50:01] anomie: can you review https://gerrit.wikimedia.org/r/#/c/158323/ when you have time? it's over a year old now [19:51:40] * legoktm piggybacks with https://gerrit.wikimedia.org/r/#/c/160411/ [19:51:52] legoktm: https://github.com/wikimedia/composer-merge-plugin/pulls [19:51:58] :P alright [19:52:02] * legoktm switches floors [20:31:43] bd808: merged \o/ [20:31:59] sweet! [21:36:41] jackmcbarn: in the commit message and some of the comments you mention backward-incompatible changes. will anything actually break? [21:43:52] jackmcbarn: you have a good track record of knowing what you're doing and the change comes with tests, so I could merge it if you like, unless you explicitly feel uncertain about some aspect of it and want feedback [22:46:27] legoktm: i've started to go through the proposed events to send using rcfeed, and i've already come across a couple of feeds that are a part of RecentChange, but aren't passed along by MachineReadableRCFeedFormatter [22:46:50] which ones? [22:47:15] for example, the edit event schema wants the user id and text, but MachineReadableRCFeedFormatter only has the latter [22:47:33] and it doesn't contain the page id [22:48:30] i haven't looked through the other events (i will), but was wondering if adding them was going to be a problem [22:49:19] adding page id and user id should be easy to do [22:49:48] it won't break anything? [22:50:06] since we're adding additional fields, I don't think so [22:50:12] ok [22:50:22] yeah, that was my hope :) [22:54:32] legoktm: TIL drupal uses composer-merge-plugin in their core composer.json :) [22:54:36] https://packagist.org/packages/wikimedia/composer-merge-plugin/dependents [22:55:05] woaaaaaah [22:55:07] :DDD