wbstack/mediawiki/pull/348

Have tested this locally by:

• checking out main branch of the deploy repo and applying it to my local cluster
• tweaking the api db provision and use versions ( wikiDbProvisionVersion: mw1.38-wbs1 + wikiDbUseVersion: mw1.38-wbs1) to be 1.38
• checking out the patch (https://github.com/wbstack/mediawiki/pull/348) locally
• building and deploying this new image using skaffold (skaffold run -m mediawiki-139)
• running the update process as follows:
  • marking wiki read only (kubectl exec -it deployment/api-app-backend -- bash -c "php artisan wbs-wiki:setSetting domain peanutwiki.wbaas.localhost wgReadOnly migrate-to-139")
  • in a second terminal tailing the mediawiki backend logs k logs --follow mediawiki-139-app-backend-c84fd9ddb-fhnzp
  • dispatching the update job form the scheduling pod kubectl exec -it deployments/api-scheduler -- bash -c "php artisan job:dispatchNow MediawikiUpdate wikis.domain peanutwiki.wbaas.localhost mw1.38-wbs1 mw1.39-wbs1 mediawiki-139"

• I then confirmed that I saw update in the constantly tailed logs

n.b. the actual update failed with the following error:

"PHP Warning:  Failed loading Zend extension 'xdebug' (tried
: \/usr\/local\/lib\/php\/extensions\/no-debug-non-zts-20190902\/xdebug (\/usr\/local\/lib\/php\/extensions\/no-debug-non-zts-20190902\/xdebug: cannot open shared object file: No such file or directory), \/usr\/local\/lib\/php\/extensi
ons\/no-debug-non-zts-20190902\/xdebug.so (\/usr\/local\/lib\/php\/extensions\/no-debug-non-zts-20190902\/xdebug.so: cannot open shared object file: No such file or directory)) in Unknown on line 0"]

but we aren't that interesting in this; just wanted to confirm that we do indeed see the stdout in the container/pod logs

Today I tested this like Tom described above and also with this PR
https://github.com/wbstack/mediawiki/pull/350/files

I also only see stdout in the pod logs and no stderr, also note that it gets mixed with ongoing http probing log entries.

re: to the question of "does the script and child process spawned by proc_open still run without curl": I think if the parent PHP process stops the spawned child process stop as well, but what I could observe is that it keeps running if you abort your local kubectl command, probably because it's already handled by the API scheduler, even when using dispatchNow.

Overall I think I tend towards rolling with how the process works right now and rather refactor it utilizing k8s jobs similar to what we discussed earlier today.

Today I added some small tweaks to the PR:

• write stderr output to stdout
• write newlines

I couldn't find a way though around the issue that we'll see stdErr output only after the stdOut output.

Overall I think I tend towards rolling with how the process works right now and rather refactor it utilizing k8s jobs similar to what we discussed earlier today.

I would also argue the current process works as expected given the architecture. If we wanted to make it better (there definitely is room for improvement), doing this in k8s jobs which give us the logging behavior we'd want as a side effect would be the preferred solution.

Note to self: Needs to be addressed latest roughly 2 weeks before the next major MW version update.

@dang I had a quick look at this and wanted to make sure the current scope of the work for this ticket is clear.

I think what would be the right thing to do would be to "dust off" this PR (i.e. try and see if the functionality from it is still workable). You could do this by following the steps I went through ages ago in T334920#8789328.

Perhaps you could then answer the questions:

• is it possible to see the standard out and standard error from update.php
• if not how hard does it look like it would be to make this happen by updating the PR