[00:39:04] Hi. [00:39:18] Wait, shit's moving again?????? [00:39:57] "again" being 6 years later, yes [00:40:15] I mean, I never had any love for the name wmflabs.org. [00:40:56] mzmcbride@tools-sgebastion-07:~$ become mzmcbride [00:40:59] groups: cannot find name for group ID 51697 [00:41:09] Is what I'm actually here about tho. Can I ignore this error/warning(???)? [00:41:39] yes. I haven't quite figured out why some group ids are failing LDAP lookup, but it hurts nothing [00:43:35] the toolforge.org change has been planned since we did the Cloud Services rebranding -- https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/Rebranding_Cloud_Services_products#Changing_domain_names [00:44:55] The big win for tools will be per-tool hostnames which will clean up a lot of nasty problems with cookies and XSS -- T125589 [00:44:56] T125589: Allow each tool to have its own subdomain for browser sandbox/cookie isolation - https://phabricator.wikimedia.org/T125589 [00:46:41] wmflabs.org is going to be replaced with wmcloud.org in most other places. The best part of that in my opinion is getting rid of that "f". It's not the Foundation's project, it's the movement's [00:47:21] we will of course be keeping redirects alive for the old domains and routes [01:25:19] oh - that reminds me, bd808, did you blacklist "login" for tool names yet? [01:25:53] https://wikitech.wikimedia.org/w/index.php?title=MediaWiki:Titleblacklist&diff=1852079&oldid=1851172 [01:27:12] login.toolforge.org and dev.toolforge.org are in DNS already. I've been using them to connect to the bastions for a couple of weeks. [01:28:36] so is dev going to be the heavy-load alternate domain for ongoing tasks, etc? [01:29:32] https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Bastion_hosts [01:29:45] it is the secondary bastion, yes [01:30:21] still not a great place to do big things, but nicer than clogging up the bastion that most folks use [01:38:03] somewhat of a related question regarding load balancing, which is more of a concern as far performance? Heavy file/database processing, or network activity? [01:39:53] I am not sure I understand the question. [01:40:28] Are you asking what is most impactful on the bastions? [01:40:34] basically [01:41:38] I guess my answer would be consumption of finite local resources. So CPU, RAM, and IOPS. Waiting on network endpoints is a negligible cost. [01:43:09] In an ideal world, the bastions are only for launching processes on either the Kubernetes cluster or the grid engine cluster. [08:15:35] Yes, completely agreed, re: foundation in wmflabs.org. [14:56:31] !log tools.quickcategories deployed 5e1e3d97ac (follow redirects by default, !title to edit the redirect itself) [14:56:34] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [14:56:49] wm-bot: are you there? [14:58:07] echo test [14:58:15] ok, so it’s working, just the instance name changed [14:58:48] we have wm-bridgebot too [14:58:53] this is new to me [14:58:59] huh, ok [15:03:03] anyways, https://gerrit.wikimedia.org/r/572489 should fix dologmsg in Toolforge [15:04:18] hauskatze: wm-bridgebot sounds like it’s https://wikitech.wikimedia.org/wiki/Tool:Bridgebot, i. e. matterbridge (IRC⇔Telegram)? [15:05:06] Looks like it, yep [15:05:14] Danke lucaswerkmeister :) [15:06:19] sounded to me it'd be some sort of wikidata-bridge thing [16:32:22] TIL wm-bot is referenced in operations/puppet.git [16:49:44] !log tools.integraality "Deploy latest from Git master: 0fcb522 (T243780), 4cb6a5a (T243780, T239067)" [16:49:49] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [16:49:49] T239067: Set up property dashboards for FindingGLAMs campaign - https://phabricator.wikimedia.org/T239067 [16:49:49] T243780: Support other wikis than Wikidata - https://phabricator.wikimedia.org/T243780