Page MenuHomePhabricator

Define variant Wikimedia production config in compiled, static files
Open, NormalPublic

Description

Arising from James's previous musing, and discussions at the 2019 Hackathon.

What

  • 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.

Inheritance tree:

allwikis.yaml
| Default values for all wikis (e.g. wgNamespacesWithSubpages which is over-ridden, or wgEnableCanonicalServerLink which isn't)
|
+- wikipedias.yaml
   | Standard values for Wikipedias, where they differ from defaults (e.g. wgSitename or the fallback logo) and special inheritances
   |
   +- dewiki.yaml 
        Bespoke values for the German Wikipedia (e.g. the logo, or FlaggedRevisions configuration) and other special inheritances

Comparison:

TaskCurrent situationFuture state
Config authored inInitialiseSettings.phpwikipedias.yaml etc.
Config build stepRuntime cache, in /tmp/Build time static file, in /srv/mediawiki/
mw-config mergeTrivial rebaseFull production build of on JSON static file per wiki
Config read stepFrom cache or computed liveAlways read from built static file

Pros

  • 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.

Cons

  • Merging is harder (and slower?).
  • Harder to audit all wikis' config for settings that "shouldn't" be over-ridden, or see how values vary.
  • 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. We're not reading them in prod, only in CI.

Former questions

  • Deterministic sort of output files to avoid noise.
    • Assuming that alphasort of the array by keys (ksort) sufficient.
  • How do we do splicing in private settings at run time?
    • Private settings are already spliced in in CommonSettings; no change.
  • Syntax for specifying config, and that a document inherits from another.
    • Roughly worked out; to be documented.
  • Syntax for specifying that descendent config can't over-ride (e.g. wgContentHandlerUseDB)
    • For now, this is just a simple all.yaml file that is re-applied at the end and so can't be over-ridden.
  • Do we need to vary on the PHP run-time still? (once HHVM is un-deployed can this go away, or are there reasons beyond PHP serialisation format that we think this might vary?)
    • No. Nothing has been variant between HHVM and Zend for a while. No reason to continue.

Open questions

  • How does the CI work for this?
  • Do we need to check on build time that a vanilla MediaWiki install (i.e., DefaultSettings) doesn't set any config that isn't represented in all.yaml?
  • What do we do about variant non-static config?

Planned steps

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

2- indentation is tricky and problematic sometimes. You know, like this.

Let me drill down on this a bit. The most annoying part is when you make a mistake in json, it explodes, it gives you error "Unable to parse json" but when you make a mistake in yaml, it works but the output is changed in a sneaky way and it explodes when you deploy it :)

Instead of splitting this per-wiki, I'd rather see similar config settings grouped together in the same file (potentially using the same groupings that DefaultSettings.php already uses), with their per-wiki overrides. I think that's more similar to the direction that config in MediaWiki core is eventually (hopefully) going to go.

I would be overwhelmed by a directory with 84 little config files in it. If we're talking some sort of hierarchical 'here's the defaults file, here's the few wikis with exceptions' and it really is a few, not hundreds, then it would make sense to split them out. Just my .02€

hashar added a subscriber: hashar.EditedJun 12 2019, 9:25 PM

@Ladsgroup what sort of issues have you had with yaml in python? How complicated are the structures you needed to represent?

1- There's no built-in support for yaml in python, you need to install pyyaml and sometimes security issues would have been exposed, like T214560: [CVE-2017-18342] pyyaml vulnerability in netbox deploy repository 2- indentation is tricky and problematic sometimes. You know, like this.

PyYAML has a load function which is would unserialize YAML to an object and would happily execute arbitrary code, which is not safe. The proper way to load the YAML file is to instead use the safe_load function. It is not an issue with YAML itself, more about the default proposed by the PyYAML implementation. load is unsafe. Luckily in latest versions that now emits a warning and folks are instructed to use safe_load instead.

The CVE got filled to expose the problem and its being addressed to have defaults "sane" to humans.

Regardless, I would rather not introduce python as a required software for operations/mediawiki-config.git. It sounds nicer to use PHP and we already use some library to add YAML support (in Translate via a composer dependency iirc). So that YAML support is a solved problem already.

https://github.com/krakjoe/uopz/commit/e94fe6cace79edc700e520045b485f97605b24d2 is an indentation trouble. Surely Json does not have those troubles since it does field delimitation based on comma. That has its own trouble as well:

{ wgFoo: [
  'default' => 1,
 'enwiki' => 2,
]
}

That is not valid due to the trailing comma on the third line. I also argue that json is nice for software consumption but is far from being human friendly, primarily due to lack of support for comments.

I'm not strongly against yaml TBH, I'm just too lazy :)

+1 I am lazy as well :-] Then json has its own problem as well!

EDIT: or we could just use some plain good old PHP files which have the benefit to be in the bytecode cache!

Change 525698 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Retry "CommonSettings: Factor out variant config generation into MWConfigCacheGenerator"

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

hashar removed a subscriber: hashar.Aug 20 2019, 9:21 AM
Jdforrester-WMF updated the task description. (Show Details)

Change 507729 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] [WIP] Variant configuration: Pre-calculate config for each wiki and store it in config.git

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

Change 533592 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Write to static (JSON) as well as serialised cache

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

Change 533593 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Read from JSON, not serialised PHP

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

Change 533594 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Never write to serialised PHP, drop support

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

Yeah, that's presumably also a blocker for pre-calculate locally. Unless we remove a lot of features and complexity, that's going to be fragile and heavy at best.
A few ideas to make it work:

  • InitialiseSettings.php to return an array (easy, no longer interact with wgConf directly in that file, pass in CS.php instead)
  • Remove use of classes, functions and constant in its value computation (easy-ish, not something we do much. Main one is NS constants, which we could maybe turn into class constants within wmf-config e.g. Wikimedia\MWConfig\Namespaces::FILE = 4). Hardcoding that is ugly, but necessary to make it independent. Should be safe anyway, given we don't allow changing these. We also kind of do it already, given we have a copy of defines.php here for testing. We'd be able to rid that.
  • Remove any reliance on the '+xyz' array-merge feature of SiteConfiguration. This is the main issue and reason why we rely on having access to MW-core's DefaultSettings and all the registered extensions' settings - it's to be able to merge complex values.

After that we'd be left with a standalone computable config.

It would compute for each wiki the globals that need to be set over top of the core/ext defaults (same as we do today).

Change 525698 merged by jenkins-bot:
[operations/mediawiki-config@master] CommonSettings: Factor out variant config generation into MWConfigCacheGenerator

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

Tagging scap as this implies changes to scap's code.

@Jdforrester-WMF Do you want to try incorporating some of those ideas and requirements necessary to be able to build the expanded config ahead of time? (for the use cases of local/CI/Git etc).

There's not an urgency on the intermediary progression from serialised PHP to JSON as far as I know, and I'd rather get that in place at the same time, possibly rebased ahead of it even so as to have full test coverage before going into these other changes as well (such as the multi-file config and e.g. YAML).

Change 533592 merged by jenkins-bot:
[operations/mediawiki-config@master] Variant configuration: Write to static (JSON) as well as serialised cache for testwiki

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

Mentioned in SAL (#wikimedia-operations) [2019-09-10T17:31:12Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: Variant configuration: Write to static (JSON) as well as serialised cache for testwiki T223602 (duration: 01m 02s)

@Jdforrester-WMF Do you want to try incorporating some of those ideas and requirements necessary to be able to build the expanded config ahead of time? (for the use cases of local/CI/Git etc).
There's not an urgency on the intermediary progression from serialised PHP to JSON as far as I know, and I'd rather get that in place at the same time, possibly rebased ahead of it even so as to have full test coverage before going into these other changes as well (such as the multi-file config and e.g. YAML).

Yeah, I've been thinking about that. Will update this task.

Change 536321 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] beta: Remove unused wgConf feature of '+beta' tag

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

Change 536321 merged by jenkins-bot:
[operations/mediawiki-config@master] beta: Remove unused wgConf feature of '+beta' tag

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

Change 536323 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] beta: Move the only dynamic config from IS-labs to CS-labs

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

Change 536323 merged by jenkins-bot:
[operations/mediawiki-config@master] beta: Move the only dynamic config from IS-labs to CS-labs

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

Change 536345 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Remove dependency on wgConfig from wmf-config/InitialiseSettings-labs.php

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

Change 533593 merged by jenkins-bot:
[operations/mediawiki-config@master] Variant configuration: Read from JSON, not serialised PHP, for testwiki

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

Mentioned in SAL (#wikimedia-operations) [2019-09-12T23:18:00Z] <jforrester@deploy1001> Synchronized multiversion/MWConfigCacheGenerator.php: T223602 Add ability to read config from JSON, not serialised PHP (duration: 01m 04s)

Mentioned in SAL (#wikimedia-operations) [2019-09-12T23:19:32Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T223602 Read config from JSON, not serialised PHP on testwiki (duration: 01m 03s)

jijiki added a subscriber: jijiki.Sep 13 2019, 5:44 AM

Mentioned in SAL (#wikimedia-operations) [2019-09-16T15:41:21Z] <jforrester@deploy1001> Started scap: wmf-config/CommonSettings.php Variant configuration: Write JSON config for all wikis T223602

Mentioned in SAL (#wikimedia-operations) [2019-09-16T15:41:29Z] <jforrester@deploy1001> sync aborted: wmf-config/CommonSettings.php Variant configuration: Write JSON config for all wikis T223602 (duration: 00m 08s)

Mentioned in SAL (#wikimedia-operations) [2019-09-16T15:42:48Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: Variant configuration: Write JSON config for all wikis T223602 (duration: 00m 56s)

Change 536345 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove dependency on wgConf from wmf-config/InitialiseSettings-labs.php

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

Mentioned in SAL (#wikimedia-operations) [2019-09-16T16:12:17Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T223602 Inject config object into InitialiseSettings-labs rather than use wgConf global (duration: 00m 55s)

Change 535963 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Read JSON config for all wikis

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

Change 535963 merged by jenkins-bot:
[operations/mediawiki-config@master] Variant configuration: Read JSON config for all wikis

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

Anomie moved this task from Inbox to Tracking/Watching on the Core Platform Team board.

Mentioned in SAL (#wikimedia-operations) [2019-09-16T18:52:56Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: T223602 Variant configuration: Read JSON config for all wikis (duration: 00m 56s)

Anomie added a subscriber: Anomie.Sep 16 2019, 7:25 PM
  • InitialiseSettings.php (and much of CommonSettings.php) is replaced with per-wiki inheritable YAML files (to allow comments).
  • 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.

I note T212460: Adopt static array files for local disk storage of values (tracking) recommends static PHP-array files rather than YAML or JSON.

Inheritance tree:

allwikis.yaml
| Default values for all wikis (e.g. wgNamespacesWithSubpages which is over-ridden, or wgEnableCanonicalServerLink which isn't)
|
+- wikipedias.yaml
   | Standard values for Wikipedias, where they differ from defaults (e.g. wgSitename or the fallback logo) and special inheritances
   |
   +- dewiki.yaml 
        Bespoke values for the German Wikipedia (e.g. the logo, or FlaggedRevisions configuration) and other special inheritances

How would this proposed scheme handle something like this from the existing configuration?

'wmgBotPasswordsDatabase' => [
    'default' => 'metawiki',
    'private' => false,
    'fishbowl' => false,
    'nonglobal' => false,
],

Would we have to set false individually in advisorswiki.yaml, amwikimedia.yaml, arbcom_cswiki.yaml, arbcom_dewiki.yaml, arbcom_enwiki.yaml, arbcom_fiwiki.yaml, arbcom_nlwiki.yaml, auditcomwiki.yaml, boardgovcomwiki.yaml, boardwiki.yaml, chairwiki.yaml, chapcomwiki.yaml, checkuserwiki.yaml, cnwikimedia.yaml, collabwiki.yaml, donatewiki.yaml, ecwikimedia.yaml, electcomwiki.yaml, execwiki.yaml, fdcwiki.yaml, fixcopyrightwiki.yaml, foundationwiki.yaml, grantswiki.yaml, hiwikimedia.yaml, id_internalwikimedia.yaml, idwikimedia.yaml, iegcomwiki.yaml, ilwikimedia.yaml, internalwiki.yaml, labswiki.yaml, labtestwiki.yaml, legalteamwiki.yaml, maiwikimedia.yaml, movementroleswiki.yaml, noboard_chapterswikimedia.yaml, nostalgiawiki.yaml, officewiki.yaml, ombudsmenwiki.yaml, otrs_wikiwiki.yaml, projectcomwiki.yaml, punjabiwikimedia.yaml, romdwikimedia.yaml, rswikimedia.yaml, searchcomwiki.yaml, spcomwiki.yaml, stewardwiki.yaml, techconductwiki.yaml, transitionteamwiki.yaml, votewiki.yaml, wbwikimedia.yaml, wg_enwiki.yaml, and wikimaniateamwiki.yaml?

Something like 0f953f257 would be even worse.

  • It will be much clearer exactly which wikis' config is changing, so deployers have more confidence.

Is this currently a problem? I can't say I've ever encountered it.

  • Easier to compare one wiki's config with another's (e.g. "how different is dewiki from frwiki?").

Is this something we often want to do? I can't say I've ever wanted to do that.

What I usually want to see is "which wikis have which values for this specific setting?" Currently I can just look at the array for wmgBotPasswordsDatabase and see "everything has it set to 'mediawiki', except private, fishbowl, and nonglobal wikis". Now I'd have to grep every file and collate them somehow. I'd put that change into "Cons".

  • 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.

So we're going to start setting every single setting now, nothing at all using the value from DefaultSettings.php or extension.json? Shouldn't that be explicitly mentioned rather than implied? Are we sure that's something we want to do, that every train might have to update the configurations just to copy defaults for newly-added settings.

  • 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?)

Wouldn't surprise me if we run into it when we migrate from php 7.2 to php 8.0 (or whatever) someday.

  • InitialiseSettings.php (and much of CommonSettings.php) is replaced with per-wiki inheritable YAML files (to allow comments).
  • 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.

I note T212460: Adopt static array files for local disk storage of values (tracking) recommends static PHP-array files rather than YAML or JSON.

Indeed, but I don't feel the extra cost in terms of usability/maintainability

Inheritance tree:

allwikis.yaml
| Default values for all wikis (e.g. wgNamespacesWithSubpages which is over-ridden, or wgEnableCanonicalServerLink which isn't)
|
+- wikipedias.yaml
   | Standard values for Wikipedias, where they differ from defaults (e.g. wgSitename or the fallback logo) and special inheritances
   |
   +- dewiki.yaml 
        Bespoke values for the German Wikipedia (e.g. the logo, or FlaggedRevisions configuration) and other special inheritances

How would this proposed scheme handle something like this from the existing configuration?

'wmgBotPasswordsDatabase' => [
    'default' => 'metawiki',
    'private' => false,
    'fishbowl' => false,
    'nonglobal' => false,
],

Would we have to set false individually in advisorswiki.yaml, amwikimedia.yaml, arbcom_cswiki.yaml, arbcom_dewiki.yaml, arbcom_enwiki.yaml, arbcom_fiwiki.yaml, arbcom_nlwiki.yaml, auditcomwiki.yaml, boardgovcomwiki.yaml, boardwiki.yaml, chairwiki.yaml, chapcomwiki.yaml, checkuserwiki.yaml, cnwikimedia.yaml, collabwiki.yaml, donatewiki.yaml, ecwikimedia.yaml, electcomwiki.yaml, execwiki.yaml, fdcwiki.yaml, fixcopyrightwiki.yaml, foundationwiki.yaml, grantswiki.yaml, hiwikimedia.yaml, id_internalwikimedia.yaml, idwikimedia.yaml, iegcomwiki.yaml, ilwikimedia.yaml, internalwiki.yaml, labswiki.yaml, labtestwiki.yaml, legalteamwiki.yaml, maiwikimedia.yaml, movementroleswiki.yaml, noboard_chapterswikimedia.yaml, nostalgiawiki.yaml, officewiki.yaml, ombudsmenwiki.yaml, otrs_wikiwiki.yaml, projectcomwiki.yaml, punjabiwikimedia.yaml, romdwikimedia.yaml, rswikimedia.yaml, searchcomwiki.yaml, spcomwiki.yaml, stewardwiki.yaml, techconductwiki.yaml, transitionteamwiki.yaml, votewiki.yaml, wbwikimedia.yaml, wg_enwiki.yaml, and wikimaniateamwiki.yaml?

Obviously not. It'd be set in private.yaml etc..

Something like 0f953f257 would be even worse.

  • It will be much clearer exactly which wikis' config is changing, so deployers have more confidence.

Is this currently a problem? I can't say I've ever encountered it.

Yes.

  • Easier to compare one wiki's config with another's (e.g. "how different is dewiki from frwiki?").

Is this something we often want to do?

Yes. Converging wikis' configuration is a long-term goal.

I can't say I've ever wanted to do that.
What I usually want to see is "which wikis have which values for this specific setting?" Currently I can just look at the array for wmgBotPasswordsDatabase and see "everything has it set to 'mediawiki', except private, fishbowl, and nonglobal wikis". Now I'd have to grep every file and collate them somehow. I'd put that change into "Cons".

Sure, will tweak existing wording.

  • 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.

So we're going to start setting every single setting now, nothing at all using the value from DefaultSettings.php or extension.json? Shouldn't that be explicitly mentioned rather than implied? Are we sure that's something we want to do, that every train might have to update the configurations just to copy defaults for newly-added settings.

This is preparatory work for the post-train world. Surprise is the enemy of automated deployment.

  • 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?)

Wouldn't surprise me if we run into it when we migrate from php 7.2 to php 8.0 (or whatever) someday.

Yeah, we can certainly stash the runtime into the header like we currently do with the mtime and re-gen based on that, too.

Change 533594 merged by jenkins-bot:
[operations/mediawiki-config@master] Variant configuration: Never write to serialised PHP, drop support

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

Mentioned in SAL (#wikimedia-operations) [2019-09-18T20:15:38Z] <jforrester@deploy1001> Synchronized wmf-config/CommonSettings.php: Variant configuration: Never write to serialised PHP T223602 (duration: 01m 04s)

Jdforrester-WMF updated the task description. (Show Details)
Krinkle added a comment.EditedSep 19 2019, 8:12 PM

Change 507729 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] [WIP] Variant configuration: Pre-calculate config for each wiki and store it in config.git
https://gerrit.wikimedia.org/r/507729

I'm not sure this is worth optimising. It would mean having to run this pre-commit, keeping all versions of this in Git history indefinitely in their expanded form, and the rebase inconvenience as a result. If the overhead of reading InitialiseSettings (or it's N JSON file equivalent in the future) is too slow to do on-demand for the occasional cache miss after a deployment, then perhaps we can let Scap pre-populate the directory as-needed?

From a quick napkin calculation though, I think we'd be fine doing that on-the-fly as before. We've confirmed that now with the use of JSON for the tmp file that it's not as expensive as I thought. Worth a try?

Basically YAML as proposed, possibly with a JSON conversion as well still, but without expansion. Also, disallowing use of dynamic merges and substituting defaults for anything that has at least 1 variant, makes sense to me, and I do think it's worth pursuing that still. That would also keep this logic much simpler and means we won't need the duplication of SiteConfiguration logic the long term, nor during the transition.

Change 507729 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] [WIP] Variant configuration: Pre-calculate config for each wiki and store it in config.git
https://gerrit.wikimedia.org/r/507729

I'm not sure this is worth optimising. It would mean having to run this pre-commit, keeping all versions of this in Git history indefinitely in their expanded form, and the rebase inconvenience as a result. If the overhead of reading InitialiseSettings (or it's N JSON file equivalent in the future) is too slow to do on-demand for the occasional cache miss after a deployment, then perhaps we can let Scap pre-populate the directory as-needed?

We could, but the advantage of having the files in-repo is that diffs are visible to users as to the impact of their changes (see above).

From a quick napkin calculation though, I think we'd be fine doing that on-the-fly as before. We've confirmed that now with the use of JSON for the tmp file that it's not as expensive as I thought. Worth a try?

For the current use-case I imagine it'd be fine to do it live, but I don't think it would be for the next step of actual compilation ( https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/538129/ ); the complexity and cost of dblist calculations is one of the things we're saving by "compiling" at merge time rather than ad hoc live in production when a request hits a wiki.

Basically YAML as proposed, possibly with a JSON conversion as well still, but without expansion. Also, disallowing use of dynamic merges and substituting defaults for anything that has at least 1 variant, makes sense to me, and I do think it's worth pursuing that still. That would also keep this logic much simpler and means we won't need the duplication of SiteConfiguration logic the long term, nor during the transition.

It's not duplication if we delete SiteConfiguration from MediaWiki.

Change 537220 had a related patch set uploaded (by Krinkle; owner: Jforrester):
[operations/mediawiki-config@master] Move VariantSettings back to InitialiseSettings now that the migration is done

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

Change 537220 merged by jenkins-bot:
[operations/mediawiki-config@master] Move VariantSettings back to InitialiseSettings now that the migration is done

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

Change 539007 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] noc: Refresh conf symlinks following 3373247e123b538

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

Change 539007 merged by jenkins-bot:
[operations/mediawiki-config@master] noc: Refresh conf symlinks following 3373247e123b538

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

Review of overall approach on using YAML perf restrictions/flexibilities (e.g. what should def be cached, and what would be fine to do at run-time) now pencilled in for Q3, maybe Q2. Not expecting to involve TechCom or CPT right now, but depending on how ambitious we want to be, might make sense to involve one or both at some point, but hoping right now to keep it isolated enough to not be cross-cutting

jbond added a subscriber: jbond.Tue, Oct 22, 9:04 AM

Change 538129 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Allow for YAML-based inheritance of configuration

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

Change 545411 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] Variant configuration: Generate dblists from YAML

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

Hey @Jdforrester-WMF I'm looking around at the last patchset and not really understanding where the db lists will be and how the yaml will be used to generate the *dblist files. When the dust has all settled, where would a script go to look for the list of, say, closed dbs? (Assuming not a MediaWiki script and not even in php.) I ask because I'll need to update the dump scripts and other related tools if this is changing. Thanks!

Change 547283 had a related patch set uploaded (by Jcrespo; owner: Jcrespo):
[operations/puppet@production] check_private_data: ignore comments on private.dblist

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

Change 547283 merged by Jcrespo:
[operations/puppet@production] check_private_data: ignore comments on private.dblist

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

Change 538129 merged by jenkins-bot:
[operations/mediawiki-config@master] Variant configuration: Allow for YAML-based inheritance of configuration

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