All done! @Gehel merged and did the deploy today: https://twitter.com/wikimediatech/status/877940072477319168
Looking back through IRC logs, people have definitely used this function manually (although I'm not sure why, exactly :)). I would argue we keep this function, though. Having some extra sloc for the flexibility to move a single server to a wikiversion that has never had its l10n compiled on tin is a good trade off, I think.
From the scap side of things the code looks fine. Looks like this will require some fiddling with pip and tox to get tests passing again :(
This is no longer happening afaict and it seems like the main followup is on T168036: rebuildTermSqlIndex.php causing beta-update-databases-eqiad to timeout and abort.
Landed D677, will close this task when new scap version (3.6.0) is released.
Mon, Jun 19
Wed, Jun 14
Mon, Jun 12
Fri, Jun 9
hrm, looks like $EXT_NAME is setup in parameter_functions.py for extensions:
Thu, Jun 8
Tue, Jun 6
D677 should handle multiple service restart/reloads.
Check out the --limit flag. That may be all you need: https://github.com/wikimedia/scap/blob/master/scap/targets.py#L50-L62
Mon, Jun 5
Hi @fgiunchedi just tagged debian/3.5.8-1. Could you update scap on carbon please? And thank you :)
This is definitely something that is on the back burner but would be nice to have
wrong workboard :)
Fri, Jun 2
I agree with the idea that we should be touching IS after all the syncs that are meant to change things on the cluster; however, I think the --beta-only-change came out of a problem with how HHVM handled reclaiming TC cache space (i.e., exploding) T149872 and T103886#1401890 both talk about this.
Thu, Jun 1
now available from integration at https://ci-staging-docker-registry01.wmflabs.org
@Gilles the mw-parser-output change in CommonSettings was created as part of https://wikitech.wikimedia.org/wiki/Incident_documentation/20170512-API can/should be removed now.
Wed, May 31
Unlicking this cookie D503: Clean up the deployment host provides needed functions for this, and does some tag cleanup, but not the actual gc-ing.
Tue, May 30
Had some trouble with the make-wmf-branch script. It seems that the AccountAudit extension repo was set to read-only in gerrit: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/AccountAudit
Will branch cut for 1.30.0-wmf.3 today in an optimistic attempt keep branching on schedule; however, I will not deploy it anywhere until T166345: wmf/1.30.0-wmf.2 performance issue for Wikipedias has been resolved and 1.30.0-wmf.2 is live on all wikis.
Tested on beta cluster and all seems to be working. @hashar has volunteered to babysit the initial deployment. Now just need an opsen around for puppet wrangling during the deployment to production. @akosiaris or @Joe can you help merge these changes/get jobrunner off trebuchet?
Mon, May 29
Fri, May 26
To recap where this issue left off yesterday:
Thu, May 25
setting as UBN! since we're stuck on wmf.1 until we can figure this out.
May 23 2017
May 21 2017
The initial step is composer dependencies, so it sounds like all wikidata extensions's composer dependencies need to be tracked somehow in mediawiki/vendor.
May 19 2017
May 18 2017
tested in a limited way, works fine.
May 17 2017
CI staging was allocated as a labs project and we've been using it for pipeline work, this is complete.
@mobrovac could you clarify a few of your requirements + rationals in comments on the google doc?