When work is done on the MCS 1.3.0 endpoint in MCS, RESTBase will need to be updated to get summary endpoint content from MCS.
(While we informally called this 2.0 before it's actually 1.3.0 since it's backwards compatible to 1.2.0)
Plan
Phase 1 / Day 1
- MCS to deploy remaining changes for summary implementation.
- RB to remove the ensure_content_type filter, so that the summary only gets re-rendered right away when a page gets edited or purged.
- RB to start the switch-over for summaries, again mainly triggered by new edits on the page.
Phase 2 (1-2 days)
- Reading to verify that the new content looks good
- No issues found by Services or Reading-Infrastructure team.
Phase 3 (2 days)
- RB to start dump for cswiki, which would make sure all summaries are re-rendered with the latest version of MCS
- RB to start dump for top five WP projects. RB can monitor SCB load and control that roll-out.
Phase 4
- RB to reapply the ensure_content_type filter, so that reads of summaries on all wikis are ensured they get the latest version.
Contingency plan
In case we need to roll back we could set the expected content type version to 1.2.0 again and depending on the severity reapply the ensure_content_type filter.
What else?
We want to get good confidence about {T184557}.
We hope to also get T184753: Use stored page leads when creating page summaries to reduce MCS load and T184751: Benchmark the new page summary API in.
Timing
We started on Tuesday Feb 20, 2018.
