[20:22:47] O/ [21:01:09] #startmeeting RFC meeting [21:01:10] Meeting started Wed Nov 26 21:01:09 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:10] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:10] The meeting name has been set to 'rfc_meeting' [21:01:26] #topic MediaWiki HTTPS policy | PLEASE SCHEDULE YOUR OFFICE HOURS: https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:34] * csteipp waves [21:01:36] #link https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_HTTPS_policy [21:01:49] o/ [21:02:01] o/ [21:02:59] So I'm up: What I'm looking for in general is a way to simply express security policies (like our complex, trying to figure out when to use http vs https) [21:03:56] As I put in https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_HTTPS_policy#Questions_for_the_RFC, I'd really like feedback on how to make the configuration as simple and expressive as possible, so no one is confused about what the policy is [21:04:34] I guess this would include the geoip stuff? [21:04:44] And second, comments on the implementation design-- like should policy enforcement be done with a callback, etc.. [21:04:51] Yep [21:05:30] The geoip lookups, and the Zero rating lookups would be "IP-based policies" [21:07:01] $securityPolicy = $config->get( 'SecurityPolicy' ); [21:07:01] $useHttps = $securityPolicy->connection->useHttps( $user, $title ); [21:07:01] is the geoip stuff in core? or would there be a hook for it? [21:07:24] this code example seems a bit strange since usually objects don't come from configuration [21:07:37] maybe you would send the configuration to a factory of some kind? [21:07:49] legoktm: No, the China/Iran policy would still be wmf specific [21:07:49] also this kind of thing: [21:07:52] $policy->addIPPolicy( SecurityPolicy::getIPPolicy( $ip ) ); [21:08:05] would that be in the factory? [21:08:21] i.e. we would have some kind of array-based configuration, and whatever reads the arrays would set up the policy object? [21:08:25] Yeah, it should be a factory [21:09:19] I just want to make sure we are doing no processing on startup, just loading configuration arrays [21:09:37] I can do that [21:10:12] maybe every request would end up loading it eventually, but still, it should be lazy-loaded [21:10:13] I think the only issue is the first policy decision comes really early-- do we redirect when the forceHTTPS cookie is present [21:10:31] But that's in MediaWiki.php currently [21:10:51] So converting config array -> policy object can happen there? [21:10:52] yeah, MediaWiki.php only applies to index.php, not to CLI or API or whatever [21:11:17] I would think that you would have a function for getting the current policy, maybe in RequestContext? [21:11:41] and that would make the policy object when it is first called [21:11:50] maybe it would be called from MediaWiki.php [21:11:57] I had thought about that.. wasn't sure if we wanted it in RequestContext or not. Definitely can do it. [21:12:18] some people don't like RequestContext... [21:12:30] but it seems to be the direction things are heading regardless :) [21:12:42] how early is this being called? I remember calling getUser too early would break stuff [21:13:08] legoktm: It's early, but needs to be after the User and Title are setup. [21:13:16] the problem with RequestContext is that it has the potential for being quite a large, monolithic assortment of unrelated things [21:13:57] I think it already is that :P [21:14:24] Daniel proposes just constructing all objects at startup [21:14:29] legoktm: And actually, that's what makes me less thrilled about it being in RequestContext, where it can be called whenever. But if we're careful about when it can be called, we can do it there. [21:14:31] in the startup function [21:15:09] that seems potentially slow to me, compared to lazy-loading [21:15:18] I like doing things lazy [21:15:21] The dependency injection and/or service locator needs of MediaWiki are complex [21:15:34] I think the two options for lazy loading are static function and RequestContext [21:15:40] I think we would crush ourselves if we did traditional DI container stuff [21:16:27] e.g. all the database stuff is lazy loaded via a static function, LBFactory::singleton() [21:16:50] all the FileRepo stuff comes initially from RepoGroup::singleton() [21:18:06] it's a bit difficult to architect new things at the moment since there is so much bile directed at the old solutions and no real clarity on what the new solutions should be [21:18:17] Alright, I'll update the code examples to focus on doing this mostly from RequestContext. [21:18:26] my inclination would be to do things the old way and let everything be migrated to the new way in a batch, once the new way exists [21:18:51] rather than just doing each individual projects in a new and distinct way [21:18:59] I think that's better than inventing yet another way that we aren't proud od [21:19:01] *of [21:19:07] Works for me [21:19:47] on another topic... your 'secure-connection' seems to be basically redirect control? [21:20:03] Yep [21:20:24] then you have cookies, maybe you would also add HSTS? [21:20:46] That would be easy to add in [21:21:01] And yeah, I would like that [21:21:19] I'm just wondering if it is definitely redirects rather than HSTS, maybe it should be called redirection or something [21:21:29] since "secure-connection" is pretty vague [21:22:17] I needed a split between "do we redirect to https" and the cookie setting, so "connection" was just the first name I came up with. [21:22:32] But yeah, hsts is think is coming, and would fit here. [21:22:40] +1 for hsts :) [21:23:00] I'll add that into the proposal [21:23:34] as for adding passwords, 2FA etc. to the policy config [21:24:03] 2FA is its own pretty complicated thing and would presumably have its own modules [21:24:20] the question will then be: what benefit does policy integration bring? [21:24:31] and I suppose the answer is per-IP, per-country configuration etc. [21:25:14] My thinking was at security criticle places (password change form, e.g.), we could do something like $policy->enforce() (if we go with callbacks). [21:25:32] you know there is a feature request for security policies that are specific to user groups [21:25:33] Then the 2fa extension can manage the policies on IP/User bases [21:25:44] e.g. bureaucrats have to have passwords with at least 8 characters [21:25:55] Yep, that's the "User" policies [21:26:06] I should call them "Group-based" probably [21:26:18] right [21:27:58] Btw, IP-based policy vs group policy-- should a policy like "bureaucrats must use https" override the "no-https from China" policy? [21:28:03] Or the other way around? [21:28:18] Configurable? [21:28:23] I'm confilicted on which, but tend to think group should override geography. [21:28:26] maybe rules should be an ordered list [21:28:45] first-wins or last-wins [21:28:52] an ACL in other words [21:29:11] rules engines always get tricky but I guess that's what is being spec'd here [21:29:11] like Apache OrderAllow ? [21:29:28] That works if they're all defined in one spot-- but to let extensions add policies is where I got stuck with that. [21:29:31] unless there is a "global" option to allow logged in users to use http ONLY, please don't move this forward.. [21:29:55] or integer priority? [21:30:02] 10, 20, 30? [21:30:14] !important [21:30:18] unspecified would have some default priority, 50 or something? [21:30:39] comets: The user preference is part of this. It won't be global yet, since there aren't global prefs, but once those are in mediawiki the preference will be there. [21:31:20] we don't support HTTP login currently, except in the blacklisted countries, right? [21:31:29] I feel like integer priorities will complicate things, but let me try it out-- hadn't thought about that [21:32:02] sorry we haven't discussed callbacks [21:32:21] https is fine for login, just not for overall usage..thats all.. [21:32:27] No http logins except based on ip currently, but that would be a policy. [21:32:28] I'm not sure how they would work exactly, but I guess something like the callback mechanism is needed [21:32:35] * aude wave [21:33:11] ok, next RFC [21:33:26] the scary one [21:33:30] #topic Extensions continuous integration | RFC meeting | PLEASE SCHEDULE YOUR OFFICE HOURS: https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:33:36] #link https://www.mediawiki.org/wiki/Requests_for_comment/Extensions_continuous_integration [21:33:50] I am looking to enhance the way we tests repositories together [21:34:03] a use case we had a few days ago was some code being removed from Mantle which passed the tests just fine [21:34:17] unfortunately that code was used by a wild bunch of other extensions such as MobileFrontend or ZeroPortal [21:34:25] luckily, it has been caught on the beta cluster. [21:34:52] If we ran the tests of the other extensions on the patch proposed to Mantle, we would most probably have caught the nasty regression and prevented the change from merging in [21:35:10] to do so, the RFC propose to have a shared PHPUnit job that will clone core + vendor + a lot of extensions [21:35:30] and run tests of all those repositories whenever a change is proposed on any of them [21:35:42] how long would that take? [21:36:02] ~15 minutes per run based on some tests I did this summer [21:36:20] probably a bit more by now. That really depends on the number of extensions we pull together [21:36:38] 5 minutes per run is already awful to have to wait for when doing SWAT. [21:36:39] the mechanism is already in action for core and vendor repositories which share the same job [21:36:50] at least as a submit job or post submit would be good [21:36:54] you know FB has a parallel test runner, including, I gather, for MediaWiki tests [21:36:57] gate & submit [21:37:10] it still takes a very long time, but they have like 100k tests or something [21:37:32] maybe that would help, running in 32 threads or so [21:37:37] the tests are definitely super slow and could probably need some investigation. parallel running would help indeed [21:37:42] but I think it is a different topic [21:38:33] I am not sure yet how to establish a list of extensions that we want to be grouped together. I believe we can start with the most important ones such as the wmf focus projects (iex: MobileFrontend, Mantle etc) [21:38:59] ones like spam blacklist tend to break when combined with wikibase [21:39:15] * aude not sure spam blacklist has any tests though [21:39:24] TimStarling: also Facebook is able to establish a list of tests to run based on the code that has been change. They manage to know that some tests can be skipped because it is not impacted by some code change. [21:39:43] that's a nice trick [21:40:09] aude: you are right, there are some nasty interactions between extensions / core. Ori tracked a few of them in MediaWiki vagrant when he attempted to run tests of all extensions for hhvm integration [21:40:22] aude: we have fixed a few issues and normalized the extensions PHP entry points. [21:40:33] * aude nods [21:40:34] TimStarling: yeah that is a different league :) [21:40:51] so would you defer the verified +2 until the integration test is done? or would it be non-voting? [21:40:58] then as more things use wikibase (e.g. wikigrok), would love integration tests to run [21:41:11] TimStarling: it would be voting preventing bad changes from landing [21:41:19] if non-voting people would ignore perhaps [21:41:39] * aude seen this with post merge jobs in core [21:41:46] the long term vision is to be able to have a set of repos @ some commits which are known to work together. Eventually one day we could get rid of the wmf branches and use the result of the integrated job [21:42:04] well, I think performance is pretty important then [21:42:13] we have seen that postmerge jobs failure tends to be ignored. the hhvm job for mw/core has been failing for ages :-( [21:42:24] and stuff on travis [21:43:09] aude: yeah the code landed, so there is little intensive to get the tests fixed, and the failure could well be caused by some other patches. Postmerge is not ideal :( [21:43:30] TimStarling: indeed. I can see 20+ minutes way to be very annoying when doing deployments such as SWAT [21:43:46] Can performance be improved by actually giving the Jenkins cluster some modern hardware? [21:44:16] TimStarling: the performance could be fixed in a few ways: add more servers + parallel testing, lot of devs efforts to enhance our tests (such as using mocking instead of loading a full stack of class / backend etc) [21:44:24] bd808: possibly, though also way the tests are designed also (e.g. split up the database interatction more from other parts) [21:44:36] e.g. for api tests [21:44:52] bd808: lot of jobs are running on labs instance nowadays. Possibly we could provision bare metal under OpenStack. Or set up an isolated bare metal cluster for CI purposes. [21:44:59] *nod* separating unit tests from full-stack integration tests would be nice [21:45:17] probably also performance analysis [21:45:23] if the MobileFrontend team want to opt in to having extension integration tests, then I guess that is OK, if they know what they are asking for [21:45:30] aude: bd808 +2 [21:45:30] e.g. we recently found we were using bcrypt passwords for test users [21:45:44] which was super slow (e.g. 33% of the time eating) [21:45:59] simple change to fix that helped a lot [21:46:01] TimStarling: from my contact with Mobile / Zero teams, they are definitely willing to have their repos tested together. [21:46:06] and yes, we probably have had very little work done on test performance ever [21:46:38] I used to look at the tests and optimize them a bit from time to time. But I am mostly focusing on the CI / QA infras nowadays [21:46:40] like the completely ridiculous idea of setting up the whole database and table structure, one CREATE TABLE query at a time, for every test that runs [21:46:46] and mediawiki/core tests are a real mess: -/ [21:46:59] The parser tests in core were ~40% of the total suite run the last time I looked [21:47:02] aude: well done! [21:47:23] most tests don't even modify the database [21:47:34] and we have a "writes done" flag already [21:47:43] you could just leave the old DB there if no writes are done to it [21:47:55] that is nice [21:48:17] also extend PHPUnit_Framework_TestCase when possible [21:48:26] if a test does not need database stuff or such [21:48:33] since time is running out, I would like to ask: do we have a consensus it is a good idea to tests repositories together? [21:48:34] instead of MediaWikiTestCase [21:48:54] Bigger picture it would be nice to separate DB calls from the core business logic of classes so the returns could be stubbed [21:49:29] hashar: it sounds to me like it is essential, so yes, in principle [21:49:35] \O/ [21:50:17] I took note we want to keep the test run overall time within reasonable limit and that 5 minutes is always super long for swat deploys [21:50:55] yeah... i hate to overrule or not wait for jenkins in swat [21:51:01] avoid at all costs [21:51:15] wfGetDB(DB_MASTER)->doneWrites() [21:51:19] seems we have a few vectors to speed them up: 1) parallel testing 2) better hardware 3) refactoring the tests to make them faster 4) kill a bunch of oddities such as having to setup/teardown the whole database. [21:51:35] just check that and skip setup/teardown if it is false [21:52:05] aude: I noticed your wikibase jobs are quite slow as well. They spend like a minute in update.php to setup the interwiki links :-( [21:52:05] If the DB in question is sqlite, set it up once and then cp it for each test? [21:52:15] hashar: indeed :( [21:52:23] anomie: sure, if doneWrites() is true then you can copy the file [21:52:48] we shoudln't need interwiki links [21:52:55] except in specific tests perhaps [21:53:01] but maybe we could even do tests against MySQL if we managed things properly *gasp* [21:53:15] imagine that, using our production DBMS [21:53:32] TimStarling: now you're just being crazy. ;) [21:54:00] should we open a new umbrella project geared toward making the tests faster? [21:54:16] I don't mind having tasks under the Continuous Integration project [21:54:21] yes, sounds good [21:54:40] project or parent task, whatever [21:55:27] also seems to start the idea, I will have to lookup for a sponsor team willing to benefit from that new system. I will probably reach out to the mobile team since they expressed interest [21:56:27] sounds good [21:56:47] ok, so RFC approved then? [21:56:54] what do you think about the RFC wiki page? Was it clear enough, does it need to be enhanced somehow? [21:57:56] I think it is good [21:58:06] #idea prevents tests teardown of the test database via wfGetDB(DB_MASTER)->doneWrites() [21:58:30] I guess I will process the backlog and write a summary + fill a bunch of tasks [21:58:45] sounds good [21:58:52] #action Antoine to write a summary of the meeting [21:59:11] #action Antoine to fill a bunch of tasks based on idea exchanged [21:59:26] #action Investigate the use of parallel PHPUnit testing (poke Timo) [21:59:44] #action Look at throwing more CPU / hardware at the problem [22:00:06] #info The gate should be reasonably fast (less than 5 minutes) since that is really annoying with SWAT deploys [22:00:20] TimStarling: thank you to have proposed to discuss this RFC here :] [22:00:31] can you make use of some old appservers hashar? ;) [22:00:37] i might have some available soon ;) [22:00:46] #agreed RFC approved [22:00:48] #info ops have some old app servers available [22:00:52] mark: definitely :] [22:01:06] mark: could use some ops brain cycles to set them up though! [22:01:07] #info some concerns about performance but I don't think that prevents the RFC from being accepted [22:03:21] nothing else to add [22:03:57] thanks for writing the RFC, hashar [22:04:00] thanks everyone for coming [22:04:08] and thanks bd808 for pushing me on it :] [22:04:33] hashar: :) you did the hard stuff. I just broke things [22:04:34] next week we will probably have... [22:04:35] thanks hashar [22:04:41] https://www.mediawiki.org/wiki/Requests_for_comment/Global_scripts [22:04:47] https://www.mediawiki.org/wiki/Requests_for_comment/Opt-in_site_registration_during_installation [22:05:04] #link http://ci.openstack.org/zuul/gating.html [22:05:12] #link https://www.mediawiki.org/wiki/Requests_for_comment/Global_scripts [22:05:16] #link https://www.mediawiki.org/wiki/Requests_for_comment/Opt-in_site_registration_during_installation [22:05:22] #endmeeting [22:05:23] Meeting ended Wed Nov 26 22:05:22 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:05:23] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-26-21.01.html [22:05:23] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-26-21.01.txt [22:05:23] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-26-21.01.wiki [22:05:23] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-26-21.01.log.html [22:05:26] not sure whether that make sense to meetbot [22:06:11] TimStarling: you should get some volunteer to have meetbot post the .wiki on mediawiki.org :-] [22:06:57] volunteer or bot [22:07:42] I am sure they can hack meetbot [22:07:52] heading out to take care of Zuul [22:57:50] Oh, I missed the chat. [23:00:26] I was going to point out that neither RFC discussed today was on the main RFC index. [23:00:41] But Tim added the extensions CI RFC to the approved section now. [23:10:01] Carmela: feel free to follow up on wikitech :-]