[04:09:01] @Site Reliability Engineers [04:09:08] on testwikibeta [04:34:53] (Image isn't visible on IRC) [04:38:13] https://cdn.discordapp.com/attachments/1006789349498699827/1115492479404359732/Screenshot_2023-06-05_at_9.08.39_PM.png [04:48:15] <:thonk:1021736285834068009> [04:51:23] odd [05:25:24] The RequestSSL stuff is because that's just an extension I've been working on and is not loaded using the correct ways. It can be removed/disabled as it's easy to re-enable when needed. [07:07:37] Fyi Freenom no longer allows .ga, and has deleted any .ga domains, it is possible a spike in .ga domains failing ssl checks and such [07:07:45] @Reception123 ^ [07:17:25] Did they not update then? [07:17:55] Seems so, the .ga domain I had registered for Miraheze was deleted with no notification [07:18:26] According to enwiki the country pulled the contract they had with freenom [07:19:35] Ah... [07:20:31] "As part of this switch-over operation, several million domain names will be deleted as the previous operator has not provided the data that concern them." [07:21:21] What I dont understand is how or why Meta is suing freenom [07:21:24] Also apparently freenom could loose others as well [07:22:39] [07:24:41] Yeah because meta being meta [07:24:58] Meta needs to mind their own business [07:26:50] If their law suit as truth in it, then I somewhat agree with them myself... [07:27:11] Freenom isnt the only one who offers those tlds for free though lmao [07:27:20] And no company ever responds to abuse complaints [07:28:22] That's the issue with the entire internet. I wish more companies were proactive in abuse reports, but since they aren't, I think some precedence set against it is good also. [07:28:46] Also about the domain parking thing, they realize the ads are based on browsing history, right? [07:30:46] I will bet that if freenom shuts down, Meta will start doing domain registrations [07:33:37] Maybe. Would make sense. And might I just randomly say here, the FaceBook rename to Meta was utterly stupid... but it could tie into this also, as one of the reasons IIRC was they wanted to expand beyond social media as well, so that definitely wouldn't suprise me to start doing those as well... [09:41:21] Well miraheze.ga is already down. I'm guessing it's likely that all other .ga wikis are down? My main concern is that if a solution is found that would mean that after removing all of them we'd have to manually re-add again. I'd propose using a script that loops RemoteWiki to remove but I don't like the fact that it wouldn't be logged. [09:42:35] Actually it seems we offer very few .ga wikis so that shouldn't a huge issue. Maybe it will if all other Freenom ones go down [09:49:01] Created https://github.com/miraheze/ssl/pull/651 and if there are no objections I think it would be best to remove in ManageWiki as well? [09:54:32] @Zppix @CosmicAlpha It seems that .ga will be managed by authorities in Gabon? I'm quite confused as to whether current domains will be reinstated or whether it will become paid and all domains will be removed. If the latter then we should remove ASAP. [14:15:56] All .ga wikis would be down [14:16:37] No, all domains are gone, when/if .ga registration is allowed it would be only paid domains and would be controlled by a french registar, I forget who, but it wouldnt be freenom anymore [14:17:09] No domains would be restored regardless [14:17:16] Ok, thanks. In that case we should just remove now. Though I won't have access until later [14:17:54] Thankfully there's less than 10 so it won't be too bad to mass remove from ManageWiki but if all freenom domains eventually go down as I said before it'd be nice to have an automatic way to do it that also logs [14:18:46] If freenom does shut down, we’ll have to decide if we want to persue other ways to register our additional miraheze domains that I control [14:19:29] Cause currently ive been renewing annually ever since I was sre [14:22:29] Probably not tbh, as it wouldn't be worth the cost [16:24:38] @CosmicAlpha any reason we can't enable parsoid everywhere [16:24:43] We need to do it before 1.41 [16:25:16] I can't think of any specific reason to not roll out everywhere [16:25:31] Given VE is probably on most wikis anyway [16:25:59] @Agent or @Reception123: can you see how many wikis do not have either VE, Flow or Linter enabled [16:27:36] 2913 wikis have VE enabled [16:28:02] 307 have Linter enabled and 146 have DT enabled [16:28:36] @Agent out of how many? [16:28:51] 6,825 wikis [16:29:01] @Agent less than half surprises me [16:29:12] I expected more than half to have VE enabled tbh [16:29:21] @Agent I was expecting most [16:29:49] I mean enabling parsoid should have basically no impact [16:30:04] Because it's just loading an extension [16:30:06] We can probably do it after we upgrade to 1.40 then [16:30:08] But I expected for most wikis they'd already have it anyway [16:38:30] @Agent https://github.com/miraheze/mw-config/pull/5243 [16:38:35] I'm happy to wait until 1.40 [16:38:43] It should basically do nothing though [16:46:51] Yes, PortableInfobox breaking, Variables, Arrays, and Loops probably also I guess? [16:47:01] Oh you mean just the extsnsion... [16:48:49] Yes just the extension which as far as I know just exposes the API [16:49:07] It shouldn't effect any actual rendering [16:49:23] Variables, Arrays and Loops should all be added to the master task [16:50:33] Updated the master task [16:51:01] But we will probably have to loose them extensions if no alternative within the next year or so [17:43:50] Variables will technically work except for just `#var_final` I believe, could add that also, and when it comes to it removing just that should be sufficient... [17:44:45] Clarify on task please [18:51:20] @CosmicAlpha @Agent is https://www.mediawiki.org/wiki/Manual:$wgParsoidCacheConfig's warmCache worth turning on [18:52:05] To the same as parser cache [18:52:13] It might cause a jump in jobs [18:52:18] We can do that now [18:57:41] https://github.com/miraheze/mw-config/pull/5245 [19:01:29] It should in theory improve performance [19:01:48] But not sure that DB / memcache will handle [19:05:29] I'm not really too well versed into caching matters, I'd defer to CosmicAlpha if he's willing to give his professional opinion [19:05:42] That's fine [19:05:44] Neither am I [19:05:56] I don't want to make the DB OOM too much [19:06:02] But that should make VE faster [19:06:26] My main concern is blowing database or memcache [19:06:28] Up [19:06:33] db121 OOMs due to something wonky so primarily it's isolated to that cluster only [19:07:37] We can't run with no parser cache though [19:07:52] Which we will be in not that long away [19:08:06] Especially if we turn parsoid on everywhere with 1.40 [19:08:21] For the rest api [19:24:17] Cc @paladox too [19:28:11] looks like the WMF are having fun with that on 1.41 already [19:35:04] @Reception123 it's been fairly seamless by their standards [19:36:24] not according to https://phabricator.wikimedia.org/T338264 [19:36:44] Reedy says it's related to REST migration [19:37:18] @Reception123 yeah we don't use restbase [19:37:28] We haven't for 2 years now [19:37:42] Restbase was what used to run on services* [19:38:50] I'm surprised they UBN'd that tbh but yeah, fair enough [19:39:22] @Reception123 any train blocker is UBN [19:39:28] That's a train blocker [19:39:34] 100%