Page MenuHomePhabricator

Investigate provisioning MediaWiki databases with a Kubernetes Job running `install.php`
Open, Needs TriagePublic

Description

This is an investigation that should be timeboxed before being picked up. It should be picked up before the next MediaWiki update (1.44 or 1.47)

It is a follow on investigation from T400609. This investigation assumes that we will create a kubernetes job to run install.php

This task is to make a small proof of concept that:

  • triggers the creation of a k8s job from the platform api that runs install.php
  • the platform API should create a new database, a new user and a password for it that should be passed to this job
  • this should result in a provisioned DB that could then be assigned to a Wiki once it is created

You will probably need to think carefully about the LocalSettings.php configuration this job has.

You should also confirm once this POC is created that the job doesn't regularly fail and the DB schema created is the same each time.

See this earlier POC using a standalone job: https://github.com/wmde/wbaas-deploy/pull/2296

A/C:

  • create a POC
  • confirm the job doesn't regularly fail
  • confirm the DB schema doesn't vary

Event Timeline

@Addshore you mention in T400609 that:

The reason behind the decision to not do that years back, is that install.php was seen as flakey, and seemingly running install.php would make it more easy to end up with varying schemas between wikis.

Did you have any records about how it was flaky and in what way the schemas might vary so that we know what to look out for?

Flakey is probably the wrong word, though of course as install.php or update.php are controlled entirely externally they could of course break for any number of unknown reasons.
So one part of the decisions around not running then, is that then they can't break.

Though the main reason for not running then in the early days of wbstack was the desire to always have all sites on a known DB state.
In the past, especially while also considering dB updates of extensions alongside core, it would be possible to do something like the following 2 sequences, and end up with a different DB schema at the end.
This is / was primarily down to how updates decide when and how to perform dB changes.

Case 1)
Fresh install of mediawiki and a set of extensions (complete) at latest version

Case 2)
Install of mediawiki at a prior version
Install of 1 extension
Update of mediawiki and extension to next version
Addition of another extension
Another mediawiki and extension update
Installation of another extension (completing the set).

Another annoying element, but likely nothing to worry about with how most of the extensions are enables / disabled, is that extensions will not install their tables to the dB if they are not loaded in local settings.
I believe some of the conditionals around wbstack "features" switch around loading the entire extension.
But from memory, these don't have dB tables.
(If the switch was / is around an extension being loaded, then the tables needs to be created at install.php time which means loading the extension then, and turning it off after, or you need an update.php when extension toggles are done)
But as said I don't think this one is actually and issue currently