This bug will likely become a tracking bug. There's a number of steps that we need to figure out with respect to git-deploy. Full list started here:
http://wikitech.wikimedia.org/view/Git-deploy_deployment
Version: unspecified
Severity: normal
Whiteboard: deploysprint-13
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27294
A few of the tasks in progress:
bug 43339: Deploy git-deploy to the Beta Cluster - Antoine is just back from vacation, and is getting started on this.
bug 43340: Design new on-disk layout for MediaWiki install on tin/eqiad Apaches - Sam and Tim are working on this.
bug 43614: l10n generation in git-deploy - Brad has started work on this.
bug 43615: Audit salt scripts for completeness (checking against scap/sync-file/sync-dir) - Aaron will be doing this.
We've long talked about moving away from scap/sync-dir/sync-file as tools for deploying code to the cluster. Ryan Lane has been working on a git-deploy based system which we hope is just about ready for deployment.
git-deploy as implemented is documented here:
http://wikitech.wikimedia.org/view/Git-deploy
We're currently planning to use this system to deploy 1.21wmf8, which is scheduled for Wednesday, January 16. The plan to move to git-deploy came together fairly quickly, which is why this is the first you may be hearing about this.
This is an ambitious plan, and so plans may yet change quickly yet. The "must do" objective driving this is a switch of the disk layout, which we want to have done prior to the datacenter migration the following week. If we're not successful with moving to git-deploy, please be aware that there will be other changes that will be done in service of that goal.
Chris Steipp and Ryan Lane will be available to help deployers transition to the new system.
It's used for parsoid and eventlogging and other deployment targets are being added. It's currently deprioritized for MediaWiki.
(In reply to comment #5)
It's used for parsoid and eventlogging and other deployment targets are being
added. It's currently deprioritized for MediaWiki.
Aha, good to know! Thank you for clarifying.
This bug came up in the context of rewriting/upgrading Wikimedia's deployment scripts (scap, etc.). It's unclear whether improving these deployment scripts (bug 27294) would be a good use of time/energy.
Until at least next quarter we won't be starting work again on git-deploy, so it makes sense to continue improving the current ones; it likely doesn't make sense to rewrite them completely, though.
reseting assignee mostly because this is a tracking bug, and I don't want the assumption that Ryan (or one person) will be tackling all blockers.
Given that the deployment group has decided to move ahead with scap3 rather than fix up trebuchet, is this bug still valid?
Well. I guess I should have clarified this task to be able deploying MediaWiki with trebuchet, but sure.
Just decline it? We are not going to use what was known as Trebuchet for mw deployment.