[14:49:44] !log admin Re-imaging cloudvirt1027 (T216195) [14:49:53] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [14:49:53] T216195: Move cloudvirt hosts to 10Gb ethernet - https://phabricator.wikimedia.org/T216195 [15:55:21] !log admin reimaging cloudvirt1028 for T216195 [15:55:24] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [15:55:24] T216195: Move cloudvirt hosts to 10Gb ethernet - https://phabricator.wikimedia.org/T216195 [16:46:18] can someone help me with a wikitech / ldap account issue? [16:46:28] a colleague exists as raja_wmde in ldap https://ldap.toolforge.org/user/raja_wmde [16:46:33] but the wikitech account doesn’t exist [16:46:41] but she can’t create it either, “username entered already in use” [16:47:08] Lucas_WMDE: THey just need to login at wikitech with the account they created using toolsadmin [16:47:47] That will "autoattach" their Developer account on wikitech [16:47:51] bd808: the problem is, she doesn’t remember her password :/ [16:47:58] and the password reset option on mediawiki doesn’t seem to work [16:48:02] I guess that requires an attached account? [16:48:12] is there a password reset in toolsadmin? [16:48:14] * Lucas_WMDE looks [16:48:34] ah! this is a known pain in the butt. I can attach the account so that the password reset will work [16:48:54] T174469 is the tracking task [16:48:55] T174469: LDAP account that is not attached on wikitech has no means for password reset - https://phabricator.wikimedia.org/T174469 [16:48:56] that would be great, thank you [16:49:14] *tries to remember that task for next time* [16:53:31] Lucas_WMDE: attachment done -- https://wikitech.wikimedia.org/wiki/User:Raja_Gumienny_(WMDE) -- they should be able to use wikitech for a password reset now [16:53:38] thank you! [16:55:09] it worked! \o/ [17:01:23] Hi y'all. The Service Ops folks sent me this way. In my work with The Wikipedia Library team, we use pulls from Dockerhub as part of our deployments to wmflabs/toolforge. Those pulls are rate-limited and sometimes cause deployment delays for us. I have two questions: 1) Is there a WMF account we could authenticate as with Dockerhub to get higher limits? 2) Could we move our images/deployments to the official [17:01:23] wikimedia hub? [17:08:55] aezell_: question 2 is one for service ops I think. As far as I know the answer to question 1 is no. From what I've read I think a single shared account would not actually be too helpful. The authed user limit is only 2x the unauthenticated limit. [17:09:53] if these are images you create yourselves, quay.io is a gratis competitor to dockerhub with no pay to play pull limits (yet) [17:38:07] hi - https://wikitech.wikimedia.org/wiki/Special:Contributions/Onlinemedicaltabletshablet --> spammer [17:45:58] hauskatze: blocked, thanks. [17:46:05] :) [18:33:50] !log admin putting cloudvirt1023 back into service T269467 [18:33:53] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [18:33:53] T269467: Upgrade nic firmware on cloudvirt1023 - https://phabricator.wikimedia.org/T269467 [20:40:55] I have a couple of Toolforge database tables that I would like to replicate to an external server. Is this supported? [20:51:55] hare: no, it is not. I think this would require very tight integration between ToolsDB and the external replication target. [20:52:12] If I'm wrong about that though, links to docs are very welcome [20:52:45] How would this work in ordinary circumstances? Would it require a configuration change to ToolDB's MariaDB server? [20:53:01] yeah, something a lot like https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-in-mysql [21:11:24] bd808: Thanks for the info. Maybe we'll pursue quay.io first. [21:16:47] aezell_: fwiw I also ran into the rate limiting issue on my Cloud VPS instance. I guess since we don't have public IPs all of our traffic is getting lumped together and we're hitting the limit way earlier [21:20:29] legoktm: yeah, this would be the same basic problem as Composer pulling from GitHub. [21:21:15] someday™ we will have IPv6 in the Cloud VPS layer which may make some of these external rate limiting issues go away [22:01:16] I wonder why more of the Internet hasn't switched to IPv6. It's 2020 and I am pretty sure I've only ever been assigned an IPv6 address a handful of times, ever [22:25:18] !log wikistats - replacing all cron jobs with systemd timers - gerrit:645455 - T265138 [22:25:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikistats/SAL [22:25:22] T265138: OKR: Work required to prepare for puppet 6 - https://phabricator.wikimedia.org/T265138 [22:26:59] hare: yea, seriously. they had "Congress To Study Slow Pace Of Migration To IPv6" in ... 2005 https://www.informationweek.com/congress-to-study-slow-pace-of-migration-to-ipv6/d/d-id/1033963 [22:27:17] I didn't know Congress even knew what IPv6 was [22:27:49] "Many critics in Washington fear foreign nations are moving ahead more aggressively with leading edge technologies than the U.S. " :p [22:28:09] https://www.theregister.com/2018/05/21/ipv6_growth_is_slowing_and_no_one_knows_why/ [22:56:46] !log tools pushed updated local copies of the typha, calico-cni and calico-pod2daemon-flexvol images to the tools internal registry T269016 [22:56:50] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [22:56:51] T269016: Cloud: workaround new docker hub ratelimits - https://phabricator.wikimedia.org/T269016