Page MenuHomePhabricator

[FY25-26 WE6.1.4] Establish Pretrain production design for MVP
Open, MediumPublicGoal

Description

hypothesis
If we document reliability risks and compensating controls to mitigate those risks, we will create a shared understanding of their implications for the Pretrain productionization design, sufficient to establish consensus on a path forward to enable an MVP.

This is follow up to the agreements made during T379683: [FY24-25 WE6.2.6] Create design document for Pretrain (née Group -1) deployment to clarify, document, and attempt to mitigate various risks to the security, performance, and reliability of the Pretrain project. We hope to come out of this phase of the project with a shared understanding of how to implement serving test.wikipedia.org traffic with code from the wmf/next branch maintained by the existing nightly Pretrain process(es) deployed by automation on a known cadence.

Details

Other Assignee
bd808

Event Timeline

bd808 triaged this task as Medium priority.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
bd808 changed the subtype of this task from "Task" to "Goal".Feb 17 2026, 10:05 PM

@Scott_French Feel free to unassign yourself if assignment tracking seems unhelpful or premature. I think the task title would be reasonable to debate or boldly change too. I started from the title in Asana, and after editing there, copied the title here.

Thanks, @bd808 - Nah, this is good, and basically identical to what I would have opened soon anyway :)

@Scott_French I have mirrored your final report to mw.o: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Pretrain/Progress_reports/2026-05-01

I'm wondering what we can do liberate the useful parts of the two google docs referenced in the closing report by putting things on wikis. Maybe something like I did for https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Pretrain#Design_agreements would work? I think the new plans actually override some of that prior planning, so updating that section does seem like a useful step no matter what.

Thank you for doing so, and apologies for the delayed response. I'll give some thought to how we can distill the most useful details from those docs.

I like the way you approached the Design agreements section you linked - the level of detail seems just right. Starting with an update to that seems like the right way to go, and from there we can figure out which aspects we want to link out to, collapse, etc. for additional specifics.