New subject: Fwd: [Maniphest] [Created] T158730: Automate WMF wiki creation

22 Feb 2017

I was talking with Tim Starling about the automation of the wiki creation,
renaming (locking, removing). In theory, this should be the first and the
most important step.

I am in favor of giving the button to stewards, as LangCom should stay
clearly a non-executive body in relation to the Wikimedia web projects.
However, it shouldn't be a big deal if we have the button, as well.

I would like to know what do you think, as well as what do stewards think
(so, MF-Warburg, may you talk with stewards about that and give us their
opinion). After we articulate our own opinions, this should be put on Meta
for wider community discussion and decision.

At this moment we don't have ETA for the application, but I suppose
something between the next couple of months and the end of the year should
be reasonable to expect, as Tim has taken that to do.

---------- Forwarded message ----------
From: tstarling &lt;no-reply(a)phabricator.wikimedia.org&gt;
Date: Wed, Feb 22, 2017 at 4:51 AM
Subject: [Maniphest] [Created] T158730: Automate WMF wiki creation
To: millosh(a)gmail.com

tstarling created this task.
tstarling added projects: Services, Release-Engineering-Team,
MediaWiki-Configuration.
Herald added a subscriber: Aklapper.
*TASK DESCRIPTION*

Wiki creation is quite an involved process, documented on wikitech
<https://wikitech.wikimedia.org/wiki/Add_a_wiki>. I think, at least for
certain common cases, the task could be almost completely automated.

For uncomplicated creation of new language editions under existing
projects, with default configuration, the following tasks need to be done,
none of which require complex human decision-making:

   - Reconfigure many services by pushing configuration changes to Gerrit,
   and deploy those commits
      - mediawiki-config: wikiversions, *.dblist
      - WikimediaMessages
      - DNS
      - RESTBase
      - Parsoid
      - Analytics refinery
      - cxserver
      - Labs dnsrecursor
   - Run addWiki.php. This script aims to automate all tasks which can be
   executed with the privileges of a MW maintenance script.
   - Run Wikidata's populateSitesTable.php. It should probably be
   incorporated into addWiki.php.
   - Run labsdb maintain-views
   - Update wikistats labs

So at a minimum, you need to write and deploy commits to 8 different
projects, run three scripts, and manually insert some rows into a DB in a
labs instance.

Despite there being no human decision making in this process, the
documentation requires that you involve people from approximately four
different teams (services, ops, wikidata, analytics).

In my opinion, something is going wrong here in terms of development
policy. The problem is getting progressively worse. In July 2004, I fully
automated wiki creation and provided a web interface allowing people to
create wikis. Now, it is unthinkable.

Obviously services are the main culprits. Is it possible for in-house
services to follow pybal's example, by polling a central HTTP configuration
service for their wiki lists? As with pybal, the service could just be a
collection of static files on a webserver. Even MediaWiki could profitably
use such a central service for its dblists, with APC caching.

So let's suppose we could get the procedure down to:

   1. Commit/review/deploy the DNS update
   2. Commit/review/deploy a configuration change to the new central config
   service.
   3. Run addWiki.php

Labs instances needing to know about the change would either poll the
config service, or be notified by addWiki.php. WikimediaMessages could be
updated in advance via translatewiki.net.

(Thanks to Milos Rancic for raising this issue with me.)

*TASK DETAIL*
https://phabricator.wikimedia.org/T158730

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *tstarling
*Cc: *mobrovac, Reedy, demon, millosh, tstarling, Aklapper, Liudvikas,
Luke081515, Eevans, Hardikj, zeljkofilipin, Jay8g, Krenair, Legoktm, greg