[05:46:12] GitLab maintenance starting soon 06:00–08:00 UTC, see T400252 for more details. I'll let you know when the maintenance is finished. [05:46:13] T400252: Gitlab switchover (gitlab2002 → gitlab1004) - https://phabricator.wikimedia.org/T400252 [07:50:58] full http 5xx stream is back in logstash cfr https://phabricator.wikimedia.org/T371366#11045857 [07:51:17] \o/ [08:07:14] jelto: don't know if something known already but creating a new MR on gitlab results in a 404 [08:07:34] Are you logged in? you have to login again [08:07:56] ah damn, sorry [08:08:53] yeah the user experience is quite bad on that side, I can open a task and check if there is some workaround for that issue. But if you are logged in you should be able to create a MR again. The maintenance logged out all users [08:09:44] it works flawlessly once I'm logged in thanks [08:09:56] great, thanks [09:13:21] <_joe_> jelto: i'm sure it's a feature you can only get with the enterprise version [09:13:58] <_joe_> non confusing logout workflow: enterprise ultimate only [09:14:07] probably yes :D [09:17:35] <_joe_> lol I made a joke, but apparently there is an "ultimate" version of gitlab 🙃 [09:17:56] <_joe_> and how can you miss, that's the 'with AI" edition [12:28:20] Looks like Debian has php-tideways but not yet php-xhprof https://packages.debian.org/stable/php-tideways [12:28:39] Its gone in testing. https://packages.debian.org/testing/php-tideways [12:29:10] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027123 [12:29:25] Looks like Mark H added it to the wishlist 3y ago [13:05:05] topranks: XioNoX I'm having issues connecting to gitlab from home using ip4, it gets to equinix but from there gets stuck [13:05:08] https://www.irccloud.com/pastebin/NOViWZp3/ [13:05:17] ip6 works ok [13:05:19] any ideas? [13:06:02] it started happening today (after the planned outage/move of gitlab) [13:06:16] it worked ~20min ago though [13:06:59] oh, and it works again :/ [13:07:15] https://www.irccloud.com/pastebin/yZYe0cPE/ [13:08:10] I'll ask again if it starts failing anew, it's the second time today that it goes away for a few minutes [13:17:59] dcaro: out of curiosity, is it expected to have cixp-salt.cern.ch in your path ? [13:18:46] I think so yes, cern is a big hub for the area [13:19:18] dcaro: historically we've had recurring issues with services that are only fronted in eqiad/codfw being accessed remotely [13:19:39] effie: cixp apparently stands for cern ixp, https://cixp.net/ [13:19:50] yes, I understand [13:20:04] one easy option to work around is `tunnelencabulator -s` [13:20:20] yep https://cixp.web.cern.ch/index.php/node/155 [13:20:31] I was not aware that it is an exchange for public consumption :p [13:20:48] interesting [13:20:48] tunnelencabulator 👀 [13:22:19] "it may also be employed in conjunction with a loopback interface reciprocation dingle arm" xd [13:24:47] awesome tool [13:24:51] ! [13:31:20] hahahahah, that made my afternoon xd [13:31:47] thanks for reporting that dcaro. How long is the issue roughly? more like a few seconds or maybe 5 minutes? It could also be some of the nftables rate limiting we have in place. [13:31:47] It looks like it's triggered more than on the codfw hosts before the switchover surprisingly [13:32:54] I'd say more like 10 min [13:32:56] dcaro: can you run the mtr again? but with these flags: mtr -T --port 443 -z -b -w -c 10 gitlab.wikimedia.org [13:33:19] it's working now though [13:33:23] my guess it it may be the return path from us, if you can share your IP with me we can check in the other direction [13:33:40] https://www.irccloud.com/pastebin/4GpXUPYM/ [13:33:46] ip6 ^ [13:33:56] well I guess the answer is "internet ¯\_(ツ)_/¯" [13:34:15] xd [13:34:25] ip4 https://www.irccloud.com/pastebin/Ql31pUXm/ [13:35:31] we won't find much if it's sopped happening unfortunately, sorry I didn't see your ping till a few mins ago [13:35:44] okok, np, hopefully it will not happen again :) [13:39:26] jelto: is there doc on how to check what IPs are currently being rate-limited/blocked? [13:41:14] I think there are no docs at the moment for that, but either sudo nft list table inet filter or checking the kernel logs on the host [13:41:14] We can also try disabling the rate-limiting [13:48:44] oh, happening again [13:48:46] https://www.irccloud.com/pastebin/8nIrbn8q/ [13:49:21] topranks, jelto ^ [13:49:36] dcaro: ok [13:49:51] was talking with XioNoX he is probably right it may be the rate limiting rather than a routing thing [13:50:13] dcaro: can you DM me your source IP from www.whatismyip.com ? [13:50:23] I have a french and or swiss IP in the denylist 213.55.xx, is that you? [13:50:58] yep, that's me [13:51:28] am I doing that big amount of queries? [13:51:31] ok then I'll disable the rate-limiting for now and we can troubleshoot why this is behaving differently in eqiad compared to the codfw host [13:51:38] probably not no [13:51:38] (I'm building things, and developing, but not as much I think) [13:53:40] let me know if you want me to do any tests [13:54:47] dcaro: it is an on going contest actually, engineers caught by the gitlab ratelimits, enter a ruffle to win gitlab swag [13:55:00] go to the gitlab shop and choose your swag! [13:55:25] jelto: did I run the wrong command, I didn't see David's IP in the list from "sudo nft list table inet filter" [13:55:37] but I could also have just been too slow as I think you changed things [13:56:01] the list has a "timeout" of 5 minutes and the IP is removed after that time [13:56:51] ok cool thanks, just checking that is the right command for my own reference [13:57:55] effie: xd I want a hoodie! [13:58:41] ah, I just found out that the budget is enough only for stickers, but you are more than welcome to buy a sticker and attach it to a hoodie! [13:59:51] hahaha [14:09:00] dcaro: thanks <3 it's an official part of `wmf-sre-laptop` :D [14:10:14] jelto: how difficult would it be to add the Report-To and NEL response headers to gitlab's responses? [14:14:38] dcaro: rate-limiting is disabled, so the issue should not happen again. We will troubleshoot this [14:14:50] jelto: thanks! [14:15:50] cdanis: currently all of the rate limiting is happening in firewall, I guess that's quite tricky to send any response headers on that layer. But we could try adding this headers to the standalone nginx [14:16:02] jelto: oh, you'd want to add it to all responses yeah [14:16:42] that could be possible, although gitlab manages quite a lot of the nginx config. But it's possible to inject custom settings [14:17:05] ack [14:17:26] https://phabricator.wikimedia.org/T303725 [14:19:17] thanks for the task, I added our tag and will add a subtask for gerrit/gitlab [14:20:25] thanks <3 tbh I've put off doing it for too long because it seemed to hard to put something in hiera that could also be dumped into VCL, and meanwhile, we haven't changed our NEL configuration at all [14:20:40] so for gitlab/gerrit feel free to just copy and paste [14:35:09] unless anyone objects, in about 10 minutes I'm going to temp disable puppet on all cp hosts to deploy and test https://gerrit.wikimedia.org/r/c/operations/puppet/+/1172402 [15:24:50] all done [15:28:10] <3