Now it’s working again, thanks a lot!

Sounds good to me; though I’m also curious what other “shared SSH”-style environments do (e.g. if the AcceptEnv adjustment is common or not). Sadly I don’t have access to a university network anymore that I could compare to 😔

It happens there as well, yes.

@taavi since you mentioned cultural imperialism in that commit message… this is pretty meh :/

After today’s reimage, this affects login.toolforge.org as well; I assume it’s also the reason I’m now seeing broken UTF-8 in my commit messages:

Apparently the Bookworm package no longer ships systemd unit files, so systemd is falling back to the SysV init scripts:

Still reproducible (tested on the sandbox item):

I see, then I misunderstood the Gerrit 3.5 release notes. Thanks for investigating!

In T334587#8831957, @taavi wrote:

• Ability to trigger builds when I push a commit to a Git repository. Most of those repos are in Wikimedia GitLab so for that I'd like it to be as simple to set up as possible, for example if it'll be webhook based I'd prefer if that was automated for repos under /toolforge-repos.

In T343131#9625722, @gerritbot wrote:

Change 991921 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Use interwiki to link to Creative Commons

https://gerrit.wikimedia.org/r/991921

Suggestion motivated by this Mastodon interaction with Julia Evans.

In T341919#9617675, @Dvorapa wrote:

Could someone point me to how to make the probe not appear in access.log for perl5.36 webservice?

It looks like the tool is still working with the new limits / requests, so I think we can call this done. Thanks everyone!

Strangely enough, despite its wording, the warning only happens for BigInt literals (e.g. 1n), not calls to the actual BigInt type (e.g. BigInt( 1 )). But I don’t think we should use the more verbose BigInt( 1 ) form just to appease a misconfigured eslint.

I’d still like to be able to increase the requests (T357209 / T357881), but otherwise this is done. (Well, eventually I should remove the grid engine code, I guess.)

In T358810#9592568, @LucasWerkmeister wrote:

Just in case you need another test case :) https://commons.wikimedia.org/w/index.php?title=Module_talk:POTY&oldid=857148097 (<nowiki><ul></nowiki>)

{{done}}

In T359098#9603104, @Jdforrester-WMF wrote:

Note that Z13530 now fails with the error bigint are forbidden in JSON.stringify.

Interestingly, this even seems to be the case right after a webservice restart, so it’s probably not (as I first thought it might be) slowness on the side of the k8s server when working in a previously-dormant namespace.

It’s mostly working for me, but I’d still like to be able to set requests.memory higher than at the moment (which is blocked on T357881 if I understand correctly).

Just in case you need another test case :) https://commons.wikimedia.org/w/index.php?title=Module_talk:POTY&oldid=857148097 (<nowiki><ul></nowiki>)

In T341919#9589241, @tstarling wrote:

If HTTP probes are configurable in service.template, can that please be documented on Wikitech? If it is not configurable, can that feature be added?

FYI, I added this to the cookiecutter-toolforge template / boilerplate for new tools now: https://github.com/lucaswerkmeister/cookiecutter-toolforge/commit/621944e6a7aa7944cafa42efef03b9b2fccbbf01

Seems to work like a charm, thanks a lot! The “only terminate old pod once new one is ready” seems to behave as expected:

I think this is completely done now :)

I don’t think so.

Looks like the required config also includes the TOOL_DATA_DIR env variable, so I can probably stop setting that explicitly. (Right now it actually shows up twice in kubectl get pod wd-shex-infer-102-dxrlz -o yaml.) Thanks!

I see… so the difference to the successful jobs in the test tool is just that I got unlucky with the placement this time. Thanks!

Thanks, the updated limitrange seems to be working!

Hm, the job ran now but something didn’t work:

(I’m leaving the job alive for now, by the way, and hope that it can successfully run once the limitrange has been increased.)

I guess I also need the limitrange increased? At least I can see a 6Gi max there.

Meh, doesn’t work, Kubernetes complained that the memory limit is immutable (if I understood the error message correctly).

The limit also isn’t working properly yet; from kubectl get events:

Setup’s looking good so far…

requests.memory is now set to 5 Gi, rather than 8 Gi as I requested. Is this intentional?

(Note: At the moment T320140 isn’t actually blocked on this, as I’m using Kubernetes directly. If I move to Toolforge Jobs, and the jobs are limited to the Procfile commands, then this would become more of an issue.)

As the migration deadline approaches, and I’m still blocked on T357209, I request that you don’t shut down my tool tomorrow until I can actually migrate it to Kubernetes.

And I might need to tweak something about how the pods are created so they don’t linger around forever. (Unless there’s a limit and it’s just not been hit yet? I know for replicasets it keeps the last 8 or so by default.)

Alright, and here’s the cleaned-up pull request to migrate from Grid Engine to Kubernetes.

Alright, some more debugging and hacking later, I have a working version of the webservice. Job #10 in the lucaswerkmeister-test tool successfully ran to completion and produced valid ShExC. It’s still using the k8s branch, specifically this commit. Next I have to address all the TODOs in the k8s code there.