Talk:Architecture Summit 2014/Configuration

Configuration -- https://www.mediawiki.org/wiki/Architecture_Summit_2014/Configuration

Configuration Database 2

https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2 https://docs.google.com/presentation/d/1eY1beeeNzOdCRJFLpN3-PjBae7uAchNvCXtH5ipgQ7c/edit?usp=sharing

• Store settings in a central database table
• Settings are stored as serialized values
• Use a mechanism similar to CentralAuth's wikisets to manage wikifarms
• Metadata stored in DefaultSettings.php
  • Can include private data that needs to be kept out of the database
• Special page to create/edit wikisets
• Special page to edit settings - like extension:interwiki
• Full history stored in config table for diffs and history
• Why not ContentHandler?
  • No place for private settings
  • Getting from zero to edit requires a lot of config
  • Fancy interface easier? Or something.

JSON Config in wiki using ContentHandler

Requests for comment/Json Config pages in wiki

Extension docs

• Not for all use cases
  • How does it work for private settings?
    • We could just not do private settings here, and have them (and only them) in the remaining stub LocalSettings.php file?
• Needed by several groups to provide configuration for Extensions etc
  • Ori's event logging use of the Schema JSON namespace
  • Yuvi's UploadWizard campaigns system
  • Zero
• How would it deal with heirarchies of values? E.g. at the moment we have them on dblist levels as well as individual wikis - CDB2 has priorities
• A pending patch for JSON content handler in the mediawiki/extensions/JsonConfig repository – https://gerrit.wikimedia.org/r/#/c/98767/
• Seeking feedback on functionality and implementation
  • What happens when the blob overflows?
    • you factored your configuration wrong. don't do that.
      • Will there be an opportunity to resize if some... extention gets bigger than initially intended?

Configuration Database

Note taker doesn't know everyone's name, please fill them in for me if you know!

Big classes of problems. What do we want to solve?:

• RobLa: Making our code base cleaner. Standard technique of configuring MediaWiki is putting a global variable into LocalSettings.php and creating hordes of global variables.
• Tim: Getting rid of global variables would break backwards compatibility with LocalSettings.php files, with extension registration files. We have the choice of sticking with global variables and moving certain use cases out of global variables (such as JSON config proposal, which avoid using global variables) or breaking backwards compatibility.
• Mark: What are the different reasons for why people want to put configuration into databases? There are use cases for third party users, especially for MediaWiki on small instances and more specialised cases. Not sure about using configuration databases for large wikis such as Wikimedia wikis, when patches can be reviewed in gerrit and tracked. Wondering if config database would be useful for WMF, although it's probably useful for third party users.
• Brion: Shoving all the existing globals into database and putting an interface on top of it is bad, due to the mix of variables used (possible secuity issues). Prefer idea of piecemeal migration to config database. Not sure if we'll have one big database or many small ones. Don't want MediaWiki sidebar. Have to figure out how to arrange configurations in a multi-site system with hundreds of sites, millions of users with different levels of access, but perhaps want to make it easy for local admins to update things like logos and adding namespaces. Unsure about one big config database in general.
• Kunal: Access restrictions, need to think more about this. Slow migration to config database may be good. Should review what should be going into a config database and what shouldn't.
• RobLa: Current main standard way of doing configuration is globals in LocalSettings.php. There are other ways, but this is the standard way.

Straw poll: How many people believe the status quo is fine for now?

• Significant support for status quo.
• Significant support for changing things up, too.

Comments from the line:

• Aude: Config database side-by-side with globals may be fine. Getting rid of globals is a good thing eventually.
• DanielK: The first step is changing the way that code uses configuration. Stop using globals directly, get Conf objects via context. Arguments against ContentHandler don't seem valid.
• TheDJ (Derk-Jan Hartman): Understand Tim being conflicted. Current configuration system is very weak. Our implementation is not acceptable by modern standards. But how do we do it, and how do we handle the current working stack properly?
• Ori: Discussion is more focussed now tahn previously. Way too much ambiguity and confusion about scope. How can we review scope? We are migrating to HHVM. There are some extensions using Yuri's code. This code merits inclusion in Core, in some shape or form, even if not active or loaded by default.
• VVV: Configuration changes used to take much longer to be processed, but it's much quicker and better now. (Thanks Reedy!) There are two problems here. First problem is configuration on single-wiki setups. Isn't there a configuration extension that solved this problem? (Doesn't work very well). Second problem is wikifarms. Not true that all configuration is stored in globals, some are stored in messages. There are some config variables that are often changed. Some config variables cannot be moved.
• TOR: In 2007, Wikia had a few hundred wikis. Configs were stored in individual LocalSettings.php. Had to find that file to change that wiki's config. So we made Wiki Factory Configurator, which does conigs for tons of wikis. This stores all the variables in a database, and lets you edit the values for them. Validates form input. Accessible to Wikia staff only, but you could surface only some variables to some people and allow them to change them, to solve the graduated user access problem. There's a (basic) changelog. Can also add new variables to override settings.
  • Not every global is a configuration setting. Not every configuration is a global variables. We need the semantics of a configuration; users don't want to set globals, they want to change site behaviour. Having third-party users able to configure their settings by a UI doesn't mean we need to get rid of globals.
• Aude: Need to make sure the system used is performant, given the size of WMF wikis.
• Chad: Config management... I'm trying really hard not to care! :-) Let's not get caught up in the backend implementation. Stock MediaWiki solutions won't work at WMF. Global config is not our biggest evil. Global object state variables are far worse. wgTitle, wgUser, wgLang that are awful state variables. Let's not fix this problem, let's try to fix global objects, there's more benefit for this.
• Tim: Don't like globals for config because it doesn't leave us with a migration path. DanielK's plan is the most extensible. I'd like extension activation to be configured.
• DanielK: For testing, you want to be able to run against current settings. You also want to be able to test whether config will work when people change settings. Do we want to invest effort in moving away from global variables? Do we want to move to using config objects, and not retrieving config variables directly? Do we want to invest in a new method for storing and managing config? That's a separate question.
  • Yuri: It's not always as simple as DanielK's solution.
• Ori: PERFORMANCE. HHVM migration should not be incumbered by large sweeping changes to the way MediaWiki starts up. Please don't change this in the next 3-6 months.
  • Matt: HHVM won't be a hard requirement for all MediaWIki users, so what do we do for non-HHVM users?
    • Ori: HHVM won't have a magic solution, but it should be a lot better.
• Matt: Internal interface changes should not conflict with HHVM, may even facilitate multiple backends.
• DanielK: Kunal's proposal needs more discussion.
  • JamesF: Implement Kunal's proposal for individual wikis and then scale up for wikifarms?
    • Chad: When we do it for MediaWiki first and WMF later, we end up with things like CentralAuth.
      • JamesF: Can learn from the mistakes we made for the single wikis, then build something more general purpose for wikifarms.

RobLa: We have a lot of considerations to make:

• Global state.
  • Straw poll: Is there an agreement on tackling the internal interface problem? Away from globals, towards objects.
    • Substantial support.
    • Minimal neutrality.
    • Minimal opposition.
• Basic hygiene of taking what's already being used (JSON configuration like EventLogging, Zero, and UploadWizard campaigns) and separating into separate extension or integrating into Core.
  • Straw poll: Is splitting JSON config out better? (independent of whether it's used for Core config)
    • Substantial support.
    • Minimal neutral.
    • Minimal opposition.
• Moving certain things from LocalSettings.php to a web interface, independent of the backend.