Jump to content

Wikimedia Release Engineering Team/Pretrain/Progress reports/2026-06-26

From mediawiki.org

Report on activities in the Pretrain project for the week ending 2026-06-26.

[WE6.7.2] Routing test

[edit]

If we create the Pretrain deployment environment using existing production MediaWiki container images and begin routing testwiki traffic to it, we will develop confidence that our routing design is sufficiently complete to support the full Pretrain MVP (e.g., all testwiki traffic is reliably served by the Pretrain environment and container).

Progress update
  • Stage: Engineering/Development
  • This week, work continued on mw-pretrain service turnup (T427668). We are now focused on bringing up a minimal "pilot" service in order to facilitate testing and validate our understanding of k8s Ingress routing. We also started to explore implementation options to support the various "flavors" of traffic diversion that will be necessary to route traffic to Pretrain (T427666), including proofs-of-concept for evaluation.
Any new metrics related to the hypothesis
  • None
Any emerging blockers or risks
  • Not yet
Any unresolved dependencies - do you depend on another team that hasn’t already given you what you need? Are you on the hook to give another team something you aren’t able to give right now?
  • No
Have there been any new lessons from the hypothesis?
  • Not yet
Have there been any changes to the hypothesis scope or timeline?
  • No

[WE6.7.3] Automated supervision

[edit]

If we implement an initial set of automated supervision strategies and enable automated deployment to the Pretrain environment for the routing test, we will develop confidence that automated supervision is ready to serve as our primary risk mitigation for the full Pretrain MVP (e.g., false positives are understood, and we have identified a path to mitigate them).

Progress update
  • Stage: Engineering/Development
  • Clarified scope/status of T428976 "Investigate dynamic threshold model comparisons for canary and production log volume checks"
    • Dynamic thresholds are not a blocker to rollout, static thresholds will suffice
    • Beyond rollout, we anticipate needing dynamic thresholds.
    • Adding more tooling similar to the already existing scap analyze-logstash is desirable.
  • Work not started on T428971 "Allow configuration of canary and production checks based on deployment target"—no blockers to starting next week.
Any new metrics related to the hypothesis
  • None
Any emerging blockers or risks
  • Not yet
Any unresolved dependencies - do you depend on another team that hasn’t already given you what you need? Are you on the hook to give another team something you aren’t able to give right now?
  • No
Have there been any new lessons from the hypothesis?
  • Not yet
Have there been any changes to the hypothesis scope or timeline?
  • No