[00:03:28] !log bd808@tools-bastion-12 tools.stashbot Updated to 25edc86 (T374875) [00:03:33] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stashbot/SAL [13:51:06] I run toolforge-jobs (One time job with --wait) , How do I make the output of this job displayed while it is running? [13:52:41]

`tail -F ~/jobname.{out,err}` [13:54:07] Is there a way from the toolforge-jobs command itself? [14:11:12] try with `toolforge jobs logs ` [14:13:50] see also the docs at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework#Job_logs [14:18:15] `toolforge-jobs run composer --command 'cd ArWiki; composer install --prefer-dist --no-progress' --image php8.2 --wait; toolforge-jobs logs composer` [14:18:31] INFO: job 'composer' completed [14:18:32] ERROR: Job 'composer' has file logging enabled, which is incompatible with the logs command [14:28:25] Is there another way to run php8.2? [14:30:26] GregesSharmon you can use the build service, with the php buildpack it runs composer [14:31:00] the tutorial is https://wikitech.wikimedia.org/wiki/Help:Toolforge/My_first_PHP_tool [14:58:45] This is an explanation of how web services work, or a project that does not provide web services, but only runs commands at specific times. [15:00:59] GergesShamon the build part should be similar, just the Procfile should change, and instead of using webservice, using them with toolforge jobs, like https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service#Job [15:07:31] @GergesShamon: for a job that you both want to wait for completion and see the output you can also try manually running things from inside Kubernetes pod. The naming here is a bit confusing, but `webservice php8.2 shell` will give you an interactive shell inside of a container with the php 8.2 runtime. [15:08:58] T311917 proposes a potentially more discoverable entry point for running interactive sessions [15:08:58] T311917: [webservice,toolforge-cli] Make `webservice shell` a standalone tool - https://phabricator.wikimedia.org/T311917 [15:18:20] !log bd808@tools-bastion-12 tools.schedule-deployment Built new image from c865012e (T374735) [15:18:23] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.schedule-deployment/SAL [15:19:15] !log bd808@tools-bastion-12 tools.schedule-deployment Restart to pick up new container image (T374735) [15:19:18] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.schedule-deployment/SAL [15:21:05] welp, can't ssh to toolforge [15:21:30] nor are any tools loading... hmm [15:22:13] arturo: anything going on with the Cloud/Toolforge network? [15:22:16] we are restarting a switch in the DC, it should not have had any effect [15:22:21] but it seems it did :/ [15:22:31] pings and ssh seem off from my side [15:22:31] bd808: yes [15:22:44] !status Networking issues [15:22:48] name resolving is not working either [15:23:06] heh. wmopbot died too [15:23:29] timed *perfectly* with me running `webservice --backend=kubernetes python3.9 restart`... like *perfectly* [15:23:34] I get no route to host, the edge routing is definitely not working [15:23:58] TheresNoTime: xd, we have a culprit then ;) [15:24:41] :D [15:26:04] Hmm … ssh: connect to host dev.toolforge.org port 22: No route to host [15:26:32] yup, folx are on it :) ^ [15:26:33] same with login.toolforge.org [15:26:41] Wurgl: known. I need to update the topic :/ [15:28:22] I jsut got into dev.toolforge.org with ssh [15:30:42] TheresNoTime, Wurgl: things are looking better now [15:30:51] yup thank you! [15:31:26] !log lucaswerkmeister@tools-bastion-13 tools.stashbot ./bin/stashbot.sh restart [15:31:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.stashbot/SAL [15:42:52] test post please ignore [15:44:02] IRC→Telegram bridge is working, Telegram→IRC bridge is probably just busy going through the backlog if past experience is anything to judge by [15:47:43] Lucas_WMDE: hmmm... logs say the bridge copied things from telegram to irc, but irc seems to disagree [15:47:58] I am seeing the irc->tlegram traffic thoug [15:48:07] * bd808 will restart the bridge [15:49:13] !log bd808@tools-bastion-12 tools.bridgebot toolforge jobs restart bridgebot [15:49:16] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL [15:51:02] ok the bridge is working again \o/ [15:51:52] !log bd808@tools-bastion-12 tools.bridgebot toolforge jobs restart bnc [15:51:53] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL [15:59:54] I think it will sort itself out if I can find patience to wait for znc [16:00:30] I was a little bit surprised, because my bot has a job with ~600 edits and it suddenly stopped. However, after ~8 minutes of doing nothing it continued [16:00:58] wow. the irc side of matterbridge resetting took much longer than I expected. [16:04:40] Dresden ist fade, nix steigt mehr [16:26:54] heh, "fixed" (I think??) a tool for someone by doing `toolforge envvars create DJANGO_SETTINGS_MODULE "backend.settings"`, even though they were doing `os.environ.setdefault("DJANGO_SETTINGS_MODULE", "backend.settings")` in app.py etc etc — just *would not* work until that was done [16:27:04] that's not "right".... right? [16:30:18] does the setdefault inherited from dict actually work to do that kind of override? [16:31:32] I guess that would be the equivalent of `os.environ[DJANGO_SETTINGS_MODULE ] = os.environ.get(DJANGO_SETTINGS_MODULE , "backend.settings")`? [16:32:14] maybe the point where app.py sets the environment variable is too late for django to pick up? (if it has to import things and such) [16:32:25] I would find that weird though :/ [16:34:56] (https://phabricator.wikimedia.org/P67265 is some context if you're interested.. was quite frustrating for the user) [16:39:21] TheresNoTime: my hunch is that `from django.core.wsgi import get_wsgi_application` actually triggers the loading of the default settings module before that `os.environ.setdefault` is parsed. [16:39:59] I agree [16:40:01] that would do it yep [16:40:02] I have a feeling that swapping the middle two lines in https://phabricator.wikimedia.org/P67265#277049 app.py might have worked [16:40:06] easy to say from over here of course [16:40:13] so https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Python#Deploying_a_Django_application might be incorrect? [16:40:32] pretty likely really [16:41:17] that whole section was written by one new toolforge user as I recall [16:42:00] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service/My_first_Buildpack_Django_tool is likely a more tested tutorial [16:46:22] added a note to the docs just in case anyone else hits that :D [16:53:39] 👍 [17:24:11] TFW you fix a thing by manually editing a file that should never need to be manually edited. #devopsLife [17:24:28] hahahahaaha [17:24:41] I just manually updated a poetry.lock file [17:26:25] “I just manually / updated a poetry / dot lock file” is *almost* a haiku [18:05:39] When using this command: [18:05:40] `webservice --backend=kubernetes php8.2 shell "/usr/bin/composer --working-dir=/data/project/gergesbot2/ArWiki"` [18:05:42] This error appears, even though this folder exists: [18:05:43] Flag --wait has been deprecated, because it is not used by this command. It will be removed in version 1.29. [18:05:45] pod tool-gergesbot2/shell-1726596168 terminated (StartError) [18:05:46] failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/usr/bin/composer --working-dir=/data/project/gergesbot2/ArWiki": stat /usr/bin/composer --working-dir=/data/project/gergesbot2/ArWiki: no such file or directory: unknown [19:37:17] @GergesShamon: the "Flag --wait" warning is a known issue and should be harmless. I think that quoiting all of the arguments you want to pass through to the shell inside the container as a single argument is causing the actual error. I would suggest trying: `webservice --backend=kubernetes php8.2 shell -- /usr/bin/composer --working-dir=/data/project/gergesbot2/ArWiki`. This may fail as well if the `webservice` cli argument parser gets [19:37:17] confused, but I think it should work. [19:51:14] 😅 chatgpt: Tell me use this command and the problem will be solved: `webservice --backend=kubernetes php8.2 shell -- bash -c '/usr/bin/composer --working-dir=/data/project/gergesbot2/ArWiki install'` (re @wmtelegram_bot: @GergesShamon: the "Flag --wait" warning is a known issue and should be harmless. I think that quoiting all of the argum...) [19:52:14] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories toolforge envvars create TOOL_EDITGROUPS__COMMONSWIKI__DOMAIN commons.wikimedia.org [19:52:16] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [19:52:57] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories toolforge envvars create TOOL_EDITGROUPS__COMMONSWIKI__URL "'https://editgroups-commons.toolforge.org/b/QC/{0}/'" [19:52:58] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [19:53:13] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories toolforge envvars create TOOL_EDITGROUPS__COMMONSWIKI__SINCE 2021-09-14T00:00:00Z [19:53:14] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [19:54:32] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories deployed 0be765159c (editgroups from envvars) [19:54:33] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [19:54:45] ouch, background-runner in CrashLoopBackOff at 199 restarts >.< [19:57:14] hm, “Connection._init_() got an unexpected keyword argument 'toolsdb'” [19:57:21] that sounds like it’s not using the right version of my code. *looks* [19:58:22] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories kubectl delete deployment background-runner && kubectl create -f deployment.yaml # recreate background runner, seemed to be running old code version? idk [19:58:24] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [19:59:19] ugh 🤦 [19:59:21] no, my code is wrong [20:00:20] !log lucaswerkmeister@tools-bastion-13 tools.quickcategories deployed 4cfe24a186 (fix background runner database config) [20:00:21] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL [20:01:15] now it’s working better, yay [20:03:05] anyway, with that I should be able to port that tool to the build service tomorrow ^^ [20:12:08] current maintenance? [20:13:56] nevermind