[14:13:38] Krinkle: I enabled the new config schema loading code on a canary host for a few minutes earlier: https://phabricator.wikimedia.org/T304460#7820896 [14:14:09] Surprisingly, it seems to be faster than loading DefaultSettings.php, even without any optimization of the loading mechanism [14:14:58] _joe_: how log do you think the config loading experiment should be live on the canary before enabling it on a job runner and an api server? And which servers should I enable it on? [14:17:11] <_joe_> duesen: the canary apis and jobrunners [14:17:16] <_joe_> :) [14:17:26] <_joe_> you can do when you want, but [14:17:37] <_joe_> how did you enable it? [14:17:56] <_joe_> i didn't think you could ssh to appservers [14:18:09] _joe_: apparently I can [14:19:05] I don't have write permission in /var/run/php, but I can sudo -u www-data [14:19:14] Did it together with ariel earlier today [14:19:24] <_joe_> what's your username? [14:19:48] <_joe_> ah wait, you're in the deployment group [14:19:53] <_joe_> so yeah [14:20:30] <_joe_> also i forget [14:20:38] <_joe_> this method won't survive a reboot [14:23:20] I'd use host name conditional for this. Not file IO. Afaik that's what we use in various places already. Should be available via uname (can't use MW util func at this point, I assume). [14:23:31] _joe_: I only need a few hours of data. [14:23:58] I haven't looked at the measuring yet. I did notice that the part measured for DS.php included some new stuff for schemas [14:24:05] Krinkle: checking file existence was Tim's idea. I find it very convenient. [14:24:37] <_joe_> i agree fwiw in this case [14:25:20] <_joe_> if you want, I can explain why it's faster to make a stat than a gethostbyname [14:25:28] Ah it's a temp file in memory [14:25:35] I didn't look at which directory [14:25:35] <_joe_> even if it was not [14:25:41] <_joe_> it's in the fs cache immediately [14:25:45] <_joe_> which is in memory [14:26:08] Krinkle: the part measuring DS indeed includes loading the config-merge-strategies.php file. We have been doing that for a while. The measurement is "fair" in that it compares the new code with the code it will replace. [14:26:24] <_joe_> the reason why I chose to go with /run is that this is indeed a temporary experiment and this doesn't require deployments [14:26:53] Yeah that way we now we can't forget to remove the files. It's neat [14:27:33] Afaik uname would be cached and reused many times in the process so that should be near free [14:36:33] Krinkle: the outcome of the measurement surprises me because when I benchmark this locally, on the command line, loading config-schema.php takes more than four times as long as loading DefaultSettings+config-merge-strategies.php. But on the live system, it seems to be faster, rather than slower [14:46:31] I'll take a look later. There can be a number of reasons for that. [14:52:35] Hi, 1.39.0-wmf.5 deployment broke video player on group1 wikis: https://phabricator.wikimedia.org/T305156 [14:53:35] matanya: both examples work for me (Firefox on Windows) [14:53:51] Yes, better to continue here :) [14:54:28] I am on Mac, and all I see is a large black bar [14:54:43] Will add screenshot to the ticket [14:56:06] Krinkle: as long as it runs fast, I'm happy :) There is no urgency in getting this live, but I want to backport it to 1.38. Would be good to have it in before rc0 gets tagged next week. [15:34:51] Nemo_bis: replied to your comment on Diff, hopefully it makes sense :) [15:51:07] cdanis: thanks for the reply, which is understandable; I may look closer to your links later [15:54:06] Krinkle: do you have major concerns about the wiki farm feature going into 1.38 as proposed in T221535? I understand that you don't like the idea of adding another way to do wiki farms. I'd like to try this idea as an experimental feature, to see what people thing. [15:54:06] T221535: Provide a "wiki farm" abstraction in MediaWiki core - https://phabricator.wikimedia.org/T221535 [15:55:11] I believe "put a file into a directory" is the easiest way to create a new wiki. In the future, perhaps the installer could support it, and our addwiki script might work on a similar principle (though we'd probably still have a build step to generate the actual config files). [15:58:26] duesen: It's really very very late to be adding things to REL1_38. [15:58:55] duesen: We properly should have shipped rc.0 already (at which point it'd be a hard-no), it was just delayed by the Parsoid stuff which landed this morning. [15:59:19] duesen: I can take it to the releasing team to make a special plea if you want, but… [16:00:25] James_F: yes, sorry, Petr leaving really put a wrench in the works. It would be unfortunate to include only part of the config overhaul. We need feedback from third parties on it. [16:01:01] The code has all been written for weeks, I have since been trying to get reviews. [16:02:33] James_F: the other thing that should really go in is "don't load DefaultSettings.php". It would be annoying to add all the code for supporting the config schema into 1.38, without the benefits. [16:03:45] Nemo_bis: sure, take your time, happy to discuss more whenever [16:05:53] James_F: the "don't load LocalSettings.php" thing is really just removing code, not adding any. [16:57:58] duesen: Sure, but it's also pretty full of horrible edge-cases. :-( [18:42:15] James_F: I am at this moment testing the horrible edge cases on the live site... [18:50:29] duesen: All of production is just edge cases held together with duct tape. [18:51:05] Indeed. [18:55:38] James_F: so the one thing I want to get in (which should ride the train next week as well) is . It just swaps which of the two cases is the default. [18:55:38] The second thing is , so people can try it out and give feedback. [18:57:00] The wiki farm thing is really more important to me. the default loading mechanism is just a little annoying, since otherwise the config schema stuff will just sit unused. [19:00:01] duesen: The first sounds reasonable. The wiki-farm support makes me more nervous. [19:09:48] James_F: the patch isn't as clean as it could be... the functionality itself is pretty self-contained. The need to loop through $wgAssumeProxiesUseDefaultProtocolPorts to avoid global variables makes it annoying. I could perhaps skip that for the backport. [19:10:34] Sure, but I'd rather the code-tested-in-master and the code-shipped-in-REL1_38 are closer than further apart, so maybe not? [22:48:58] sharing the new status page - https://www.wikimediastatus.net/ [23:05:11] Nice!