Right now the kubernetes job that run mediawiki jobs selects the image version by looking at a running backend MW pod and copying that image: https://github.com/wbstack/api/blob/1562a97ad71d013256a9fd116e116a27b431272c/app/Jobs/ProcessMediaWikiJobsJob.php#L32
However this if there is more than one backend pod I'm unsure which version will be used, if it will be deterministic or not.
A/C:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Goal | None | T368356 ⬆️Update Wikibase Cloud to MediaWiki 1.43 | ||
| Open | None | T409730 ⬆️🚦Make sure MediaWiki 1.43 DBs are only accessed by 1.43 image based pods and similar for 1.39 | |||
| Resolved | Tarrow | T408624 ⬆️ 🚦Make Mediawiki Jobs run using the correct mediawiki version |
tarrow opened https://github.com/wbstack/api/pull/989
Introduce MediaWikiHostResolver
tarrow closed https://github.com/wbstack/api/pull/989
Introduce MediaWikiHostResolver
tarrow opened https://github.com/wbstack/api/pull/993
Route backend jobs to use correct image
Please feel free to work on this while I'm out on Friday if the code needs further work, or even needs to head in a different direction after you review it; I'm not precious about it :)
Didn't make meaningful progress on this today; I can report that I tried to test this on a GCE VM but mostly spent time clearing enough workloads to fit on the 8 core cpu and then to allow skaffold to run.
I then spent too long headlessly trying to provision a wiki that I could run this new version of the process job against since I found minikube tunnel didn't seem to work for me (some GCE firewall rule?). I guess the next step is probably to put together a more comprehensive script to headlessly set up the test environment.
Managed to create a decent enough test wiki and associated stuff situation by running the following in tinker:
$user = User::find(1); $controller = app(App\Http\Controllers\WikiController::class) $request = Request::create( '/users', // randompath 'POST', ['sitename' => 'Test', 'username' => 'Test', 'domain' => "test.wbaas.dev"] ) $request->setUserResolver(function () use ($user) { return $user; }); $controller->create($request)
From my rough testing this seemed to work perfectly which surprised me considering this comment https://github.com/wbstack/api/pull/993#discussion_r2504485576 so next I need to double check if I missed something
tarrow opened https://github.com/wbstack/charts/pull/206
api 0.34.0 ServiceAccount role to add reading services
Actually made the skaffolding work and now see the error:
Authentication Exception: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"services is forbidden: User \"system:serviceaccount:default:api-defaultrole\" cannot list resource \"services\" in API group \"\" in the namespace \"default\"","reason":"Forbidden","details":{"kind":"services"},"code":403}Added the rights to list services to: https://github.com/wbstack/charts/blob/main/charts/api/templates/role-defaultrole.yaml (see: https://github.com/wbstack/charts/pull/206)
And now I get the error I would expect: Unable to find a matching MediaWiki backend service in the cluster at /var/www/html/app/Jobs/ProcessMediaWikiJobsJob.php:41)
Fixed this up by adjusting the selector.
tarrow closed https://github.com/wbstack/charts/pull/206
api 0.34.0 ServiceAccount role to add reading services
tarrow opened https://github.com/wmde/wbaas-deploy/pull/2325
staging: bump api chart version to 0.34.0
tarrow closed https://github.com/wmde/wbaas-deploy/pull/2325
staging/local: bump api chart version to 0.34.0
tarrow opened https://github.com/wmde/wbaas-deploy/pull/2326
prod(argo): bump api chart version to 0.34.0
tarrow closed https://github.com/wmde/wbaas-deploy/pull/2326
prod(argo): bump api chart version to 0.34.0
Next up is deploy this to staging; make sure a load of jobs will run on staging wikis configured on both 139 and 143 and hopefully see no errors.
tarrow closed https://github.com/wbstack/api/pull/993
Route backend jobs to use correct image