[05:06:34] taavi, could u reboot flickrreviewer_2 again? not sure what causing it to stop working randomly...must be something to do with some change in flickr api which affected uploadwizard/flickr bug too maybe [06:41:32] good morning [06:44:31] I've been able to migrate my jobs to kubernetes, but I was only able to plan python scripts. For example: for running "python3 disambig.py", now I do "toolforge jobs run desamb --command "$HOME/pwbvenv/bin/python3 $HOME/disambig.py" --image python3.11 --schedule "@monthly"". My question is how cna I execute in toolforge "sh robot.sh"? Thanks in advance [06:44:47] * can I execute [08:42:36] Hi. [08:42:37] I think instead of the command, loading the jobs from yaml file would be better for your usecase. [08:42:38] [08:42:40] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework#Loading_jobs_from_a_YAML_file (re @Pau: I've been able to migrate my jobs to kubernetes, but I was only able to plan python scripts. For example: for running "python3 d...) [08:44:30] Thanks, Kiran. I'll try to understand what is a YAML file and how can I use it [09:30:02] Pau, to run any script, it's the same, just change the command: `--command 'sh $TOOL_DATA_DIR/robot.sh'` Note that you should prefer `$TOOL_DATA_DIR` to `$HOME`, as `$HOME` might not point to the tool home directory (but the user running inside the container) [10:26:22] Hey everyone! Any help with troubleshooting my Vue/Node.js tool on toolforge would be much appreciated. I've regularly used the "webservice --backend=kubernetes node18 start" command within my "www/js" directory to kick off my web tool. [10:26:22] The start script in package.json is "npm install && npm run build && node server.js" [10:26:23] Running this today seems to finish the "build" step but never gets to "node server.js". When I check the logs, the "start" script seems to restart and tries reinstall npm packages/build vue forever. [10:26:23] Any clues? Happy to provide any more info as well. Thanks in advance! [10:29:50] !log lucaswerkmeister@tools-sgebastion-10 tools.bridgebot Double IRC messages to other bridges [10:29:51] ppenloglou: hi! that tool is very likely tripping on our monitoring which expects a tool to start within two minutes [10:29:53] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.bridgebot/SAL [10:30:20] generally our recommendation is to run any install or build steps within `webservice shell` only when needed, and have the 'start' script just start the service [10:33:04] Aha! That confirms my suspicion. I was investigating whether there was an issue "npm install" or "run build" but I successfully ran them within a webservice node shell. So would your advice be to run these in the shell and change the "start" script to "node server.js"? [10:34:25] yes, exactly [10:35:12] another option would be to use the buildservice, and then the build step would happen when building the image (`toolforge build start ...`) [10:35:50] that might require more changes though (ex. needs a public git repository, a package.json file, and a Procfile) [10:46:19] Thanks taavi!! Your steps worked just fine, tool is up and running! [10:46:19] "tripping on our monitoring which expects a tool to start within two minutes" [10:46:20] Could I read more about this on wikitech, sounds interesting ;) [10:46:35] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Health_checks [10:47:04] dcaro Not that familiar yet the buildservice, I do have a second PHP tool that uses it, will get more familiar as I develop it more [10:47:33] ppenloglou: feel free to ask for help/guidance :) [10:47:38] Cheers everyone, you've made my morning! Have a good one! [13:10:13] !log quarry deleting long-shutdown quarry-puppet-master-02 [13:10:16] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Quarry/SAL [13:20:07] !log tools cached registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.6.0 as docker-registry.tools.wmflabs.org/kube-state-metrics:v2.6.0 in the docker registry for T359798 [13:20:12] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [13:20:12] T359798: refresh kube-state-metrics version for k8s 1.24 - https://phabricator.wikimedia.org/T359798 [14:52:49] everyday that bot doesn't work, the backlog is 5000+ images a day...so yeah if any developer here has the power to restart/reboot FlickreviewR 2, please do [15:34:58] stemoc: Do you know the Toolforge tool name for "FlickreviewR 2"? I'm not seeing an obvious match at https://toolsadmin.wikimedia.org/tools/?q=flick [15:35:55] run under Yifeibot i think [15:36:12] ah. yeah, I just found "This bot runs on Wikimedia Toolforge as yifeibot." on https://commons.wikimedia.org/wiki/User:FlickreviewR_2 [15:37:13] stemoc: somebody probably should try to talk to zhuyifei1999_ to see if they can become a co-maintainer of the bot. [15:38:00] * bd808 is not volunteering [15:38:11] yeah most of the people on commons who have dev background are gone.. [15:40:49] I guess that means it is time for y'all to try and attract some new folks. I wish I had better advice than "ask around and be nice to anyone who tries to help" :/ [15:45:36] we have all the nudes on commons and its still not attracting ppl :P [15:45:39] stemoc: there are 11 different processes running under https://toolsadmin.wikimedia.org/tools/id/yifeibot. None of them have any obvious documentation on what they do and how to start/stop/restart them. Maybe one of the co-maintainers there has some secret knowledge? [15:45:52] * bd808 finds a hint at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.yifeibot/SAL [15:46:52] * stemoc bookmarks that [15:47:18] !log bd808@tools-sgebastion-10 tools.yifeibot 'kubectl delete pod flr-6d74b958d9-w7fhc' after reports of FlickreviewR 2 not working on IRC [15:47:22] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.yifeibot/SAL [15:50:05] yay [15:50:27] wonder what causes that same repetitive bug [16:06:58] !log tools.wikibugs Updated channels.yaml to: 7b84d44eff3dc778078b51c584614422889380a6 Send all Gerrit projects to wikimedia-releng [16:07:02] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wikibugs/SAL [16:07:48] When the next grid shutdown date ? (I've lost the email that mentioned it) [16:09:34] 2024-03-14, https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation [16:25:24] sohom_datta: Thursday I think [16:25:42] 2024-03-14 [20:42:06] I've installed OpenSearch on a Cloud VPS instance. Now I want to follow https://opensearch.org/docs/latest/install-and-configure/install-opensearch/debian/#configure-tls for replacing the default certificates. It says to specify a DNS A record when making the certificate. Should that be the web proxy? That seems wrong, as the proxy provides SSL termination. [20:45:40] kostajh: what is your ultimate goal for the server pool? Are you going to expose it directly to clients outside of the project? Just trying to reason about what kind of certs are going to be lowest friction for everyone. [20:47:02] In prod I think we use the Puppet keys somehow to make certs for IPC things like talking to OpenSearch. I can't remember if the same stuff works in Cloud VPS or not. [20:47:33] bd808: I plan to create a read-only user for accessing an index on the OpenSearch app. Then I'll distribute the basic auth username/password for that to some people for QA / testing. So it would be open to clients outside the VPS, but not many [20:47:49] It looks like based on https://opensearch.org/docs/latest/security/configuration/generate-certificates/#generate-an-admin-certificate I can ignore the DNS A record requirement if I am ok with disabling host verification. [20:47:58] which for the purposes of this project (proof of concept), seems fine. [20:48:21] *hostname verification [20:48:53] There is some stuff at https://wikitech.wikimedia.org/wiki/Search/adding-nodes-to-deployment-prep that might be interesting to check out [20:49:47] thx [20:50:03] Folks in Observability might have advice too. [20:51:15] We haven't bothered to add TLS to the cluster in Toolforge yet. I'm not sure that the added complexity has any major benefit since the traffic isn't allowed out of the Toolforge Cloud VPS project. [20:52:44] bd808: ty. I think I'll back up the certificates and try https://opensearch.org/docs/latest/install-and-configure/install-opensearch/debian/#configure-tls [20:54:28] self-signed time bombs :) [20:56:42] :D [23:09:31] 5