Page MenuHomePhabricator

Trebuchet blockers for MediaWiki (tracking)
Closed, DeclinedPublic


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:

Version: unspecified
Severity: normal
Whiteboard: deploysprint-13
See Also:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:01 AM
bzimport added a project: Deployments.
bzimport set Reference to bz43338.
bzimport added a subscriber: Unknown Object (MLST).

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.

Assigning meta issue to Chris for purposes of tracking. Lightly edited status email about this move included below.

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:

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.

[assigning to Ryan as RobLa said]

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.

greg renamed this task from Trebuchet blockers (tracking) to Trebuchet blockers for MediaWiki (tracking).Sep 14 2015, 3:31 PM
greg changed the task status from Open to Stalled.
greg set Security to None.

Just decline it? We are not going to use what was known as Trebuchet for mw deployment.

greg removed greg as the assignee of this task.Sep 24 2015, 11:37 PM
greg moved this task from Backlog to Done on the User-greg board.
greg removed a project: User-greg.