[03:00:04] when running a job, why is the image name required? once I set this thing up, I want it to keep running without maintenance for maybe 30 years, I don't want to have to log in every 2 years to figure out what toy story character debian has decided to use this time [03:00:36] I want this thing to stay up so long that it'll be my grandchildren figuring out how to fix it [03:32:48] ++ [03:32:56] that is something i can get behind. :) [04:08:49] write it in cobol [09:18:47] TimStarling: that's not realistic for a number of reasons: security wise, etc :-P [09:24:52] TimStarling: long-term, I think that using compiled binaries (so they only depend on the basic OS libs) + buildpacks (non-language bound, just using it for the http service) might be the combo that will be the easiest to maintain, but yep, 30 years is possibly a stretch [09:35:51] I was really just asking for the --image option to `toolforge jobs run` to be optional [09:38:36] the motivating use case is a job which is just "find $dir -mtime 30 delete" [09:39:21] find has been around in more or less its current form since 1978 and is available in all toolforge images so it's reasonable to assume it will keep working for another 30 years [09:41:47] !log admin-monitoring deleting all leaked instances by hand (11 VMs) [09:41:50] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin-monitoring/SAL [09:41:55] that's reasonable, but it's not just find that you are using, but the whole image. I think that the build-service might still be the long-term option for that, as we can rebuild the image automatically if needed, and if it's just using find, that will work in future rebuilds (as opposed of installing any libs/packages/etc.) [09:43:07] just default to an image called "default" and make it be the same as the latest debian [09:46:02] TimStarling: if you open a phabricator ticket, we will have a proper discussion in the team about how to approach that [09:51:18] Hello! Through the help received by the community here, on December I was able to migrate my tool to Kubernetes. Run one or two manual tests of it and it started working. I set up a YAML file and set it to run monthly and get notified for everything by email. Unfortunately I never got an email about it starting on whole January and have yet to get any for February so I'm suspecti [09:51:19] ng I've done something wrong somewhere (maybe with the YAML file?) [09:51:20] [09:51:22] Can anyone with "admin access" check my tool account files and see if things are right? My tool is called smallem and it's just a rather simple replace pywikibot. I've closed its migration ticket as resolved but I may be forced to reopen it if I can't solve this problem. :/ [09:53:01] Klein: can you open a task with the name of your tool? Will be easier for us to follow up and add info to it (we work on many different timezones) [09:55:34] @Klein: it seems to me like you never actually loaded the list of jobs? The jobs are defined in `smallem.yml`, but `toolforge-jobs list` yields nothing, suggesting there is a missing `toolforge-jobs load ...` step to be done [09:56:01] Yes, I can. I can do that or reopen the migration task. But I strongly suspect that nothing is wrong technically from the kubernetes infrastructure part. It's just that I might have done a small error when setting up my YAML file since it was the first time working with Kubernetes. And thus thought that maybe I can fix the issue without needing that. But if that can't be helped, [09:56:02] I will start a task, no problem. [09:57:39] I think I did that as far as I remember but I will try it again. Will set it to run daily the first time to see it in action rather fast. Just so that I'm clear, what command do I put exactly to load that list of jobs? (re @wmtelegram_bot: @Klein: it seems to me like you never actually loaded the list of jobs? The jobs are defined in `smallem.yml`, but `too...) [09:58:31] @Klein: try `toolforge-jobs load smallem.yml` [09:58:56] Thank you! :)) [09:59:26] thank you :-) [10:00:45] there is a very suspicious `toolforge jobs flush` in the history on 2024-01-04, so maybe you forgot to load them again [10:03:12] Hmm... Could be... I do remember getting one email on January about one job starting (and one for it ending) but never got one for the other two jobs. Maybe I've flushed the list and did some changes to the other two scripts back then and then never actually re-loaded the list. [10:03:54] maybe! try loading them again and report back [10:04:54] Yes. Thank you. [10:05:17] done T357388 [10:05:17] T357388: toolforge jobs current image alias - https://phabricator.wikimedia.org/T357388 [10:07:23] TimStarling: thanks, nice writeup, will definitely help us take actions [13:05:18] anyone know how to unlink a wikimedia account from an LDAP account? [13:05:37] unlink in which system? [13:11:10] I want to disconnect a wikimedia account from a developer LDAP account. I creatred the LDAP account nearly a decade ago but never did anything with it and want to connect the wikimedia account to a different LDAP account. [13:13:31] when I try to link the accounts in Toolforge via ouath it says the account is is already attached to another LDAP account. I know which account its attached to if that helps [13:13:41] and I can login to it [13:15:07] ok, so you're talking about the links in the toolforge admin console. there are a few other systems (idm.wikimedia.org and phabricator at least) which also allow logging in with a developer account and linking a SUL account, which is why I asked. [13:15:18] right [13:15:28] I don't think there's a self-service interface to do it, but I can do it for you if you give the username [13:15:57] The username of the old account is "Philip Nelson" [13:16:43] ok, done. you can now attach it to the new account [13:17:00] thank you very much [14:42:49] kindrobot: is the testing stack in the 'wikifunctions' project still in use? it seems like most web proxies in that project return a 'Host aw-xxxxxx.wmcloud.org not found' error which to me sounds like some cleanup function for the proxies being broken [18:51:00] !log lucaswerkmeister@tools-sgebastion-10 tools.lexeme-forms deployed 85b6ec6534 (l10n updates: ja, kaa) [18:51:03] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [19:07:10] taavi: it still is, but the clean up is likely broken. I'm not working on it/with the team ATM, but I'm meeting with the manager in a couple of days, and will make sure either I or someone else is tasked with fixing the clean up [21:20:58] the ssh server at login.toolforge.org is running on port 22 right? [21:21:21] yeah [21:22:24] alright. then my issue must be my on my networks side [21:22:26] * blu3r4d0n sighs [21:24:35] ssh is hanging at the login and when using -vvv the debug message it hangs on is: debug3: set_sock_tos: set socket 3 IP_TOS 0x00 [21:24:36] so not super helpful lol [21:28:52] the next expected log event would be "debug1: Connection established." so yeah, not too helpful. [21:30:32] yeah, think it's something to do with QoS [21:30:36] on my end [21:33:47] blu3r4d0n: https://wikitech-static.wikimedia.org/wiki/Reporting_a_connectivity_issue has some ideas about data to collect/tests to run that you could use to rule out routing problems. That page is written from the point of view of debugging HTTPS errors to the wikis, but the core ideas are the same. [21:34:28] bd808: thanks [22:12:38] Well it times after a bit if I pass -o IPQoS=none on debug1 connection to address. but I'll have to debug later [22:12:45] *times out [22:53:50] Hi everyone - I'm not sure if this is the right channel - please redirect if so! But I'm an engineering manager at the Foundation working with the Future Audiences team. A contractor working with our team, Elias Rut, recently submitted a Toolforge membership request, here: https://toolsadmin.wikimedia.org/tools/membership/status/1650 . The request [22:53:51] is currently pending, as the reviewer could not verify that indeed Elias was a Foundation employee. I would like to confirm that indeed he is an employee working on my team - consequently, would it be possible to move the request along? [23:02:15] NHillard-WMF: I approved it; sorry for the delay. [23:03:00] Thanks andrewbogott - Appreciate it! [23:07:21] Elias's email address in git commit has multiple @ ?? I'm surprised git even allows that.