Arising from James's previous musing, and discussions at the 2019 Hackathon.
* InitialiseSettings.php (and much of CommonSettings.php) is replaced with per-wiki inheritable YAML files (to allow comments).
* Actually-variant config goes into a much slimmer CommonSettings.php (or re-worked to not vary).
* On merge, the YAML files are converted into one JSON file per wiki, for the currently-deployed version(s) of MW, which are stored in git.
* This replaces the opportunistic cache in /tmp that we current have.
| Default values for all wikis (e.g. wgNamespacesWithSubpages which is over-ridden, or wgEnableCanonicalServerLink which isn't)
| Standard values for Wikipedias, where they differ from defaults (e.g. wgSitename or the fallback logo) and special inheritances
Bespoke values for the German Wikipedia (e.g. the logo, or FlaggedRevisions configuration) and other special inheritances
| Task | Current situation | Future state |
| --- | --- | --- |
| Config authored in | InitialiseSettings.php | `wikipedias.yaml` //etc.// |
| Config build step | Runtime cache, in `/tmp/` | Build time static file, in `/srv/mediawiki/` |
| mw-config merge | Trivial rebase | Full production build of on JSON static file per wiki |
| Config read step | From cache or computed live | Always read from built static file |
* Variant configuration will be static, making it more plausible to inject into docker images.
* It will be much clearer exactly which wikis' config is changing, so deployers have more confidence.
* YAML configuration files explicitly set the inheritance pattern.
* Easier to compare one wiki's config with another's (//e.g.// "how different is dewiki from frwiki?").
* Clear when the rump of CommonSettings refers to undefined variables; variant config forced to be merged first.
* Merging is harder (and slower?).
* Harder to audit all wikis' config for settings that "shouldn't" be over-ridden.
* Production branch pruning, currently just a disc operation and a sync, now needs a commit to mw-config as well as a deploy to delete.
* First time we're reading YAML files in PHP prod.
# Open questions
* Deterministic sort of output files to avoid noise. Is alphasort sufficient?
* How do we do splicing in private settings at run time?
* How does the CI work for this?
* Need to check on build time that a vanilla MediaWiki install (//i.e.//, DefaultSettings) doesn't set any config that isn't represented in `allwikis.yaml`.
* Syntax for specifying config, and that a document inherits from another.
* Syntax for specifying that descendent config can't over-ride (//e.g.// `wgContentHandlerUseDB`)
* Do we need to vary on the PHP run-time still? (once HHVM is undeployed can this go away, or are there reasons beyond PHP serialisation format that we think this might vary?)
# Planned steps
[x] Write cached config to JSON as well as serialised PHP https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/533592/
[ ] Read cached config from JSON not serialised PHP https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/533593/
[ ] Stop writing cached config in serialised PHP https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/533594/
[ ] Pre-calculate config for each wiki and store it in config.git
[ ] Make scap steps to change target for each wiki update cached config in config.git, not just wikiversions.json
[ ] Load config from config.git on disc, not from /tmp
[ ] Write initial YAML file reader -> JSON writer and hook into CI
[ ] Migrate initial settings from InitialiseSettings.php to YAML
[ ] Completely move all static variant config into YAML; scrap dblists and InitialiseSettings.php