This ticket is about collecting ideas, confirming desires and exploring possibilities.
The idea would be to have some patches deployed on test or group0 for an extended period of time, such as a whole week rather than a single day, before heading to group1.
Generally it would be prefered to do this using a feature flag but that has been deemed not practical for the collection of patches.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Group0 to 1.32.0-wmf.999 | operations/mediawiki-config | master | +130 -130 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | daniel | T161671 Compacting the revision table | |||
| Duplicate | None | T184615 Once MCR is deployed, drop the rev_text_id, rev_content_model, and rev_content_format fields from the revision table | |||
| Stalled | None | T174043 Deploy Multi-Content Revisions | |||
| Resolved | daniel | T174044 Deploy MCR storage layer | |||
| Resolved | Addshore | T196585 Deploy some MCR related patches on test / group0 for an extended period |
One idea would be to create an extra branch for the train / week. So for example having a wmf.x branch without the above changes but also a wmf.x+mcr branch.
The deployment could then look something like:
Tuesday: Create wmf & wmf+mcr branches, Deploy wmf branch to group0
Wednesday: Deploy wmf branch to group1, Deploy wmf+mcr branch to group0
Thursday: Deploy wmf branch to group2
This could be done in combination with the upcoming no deploy week, which would result in the mcr related code being on group0 for over 1 week.
The MCR code is backwards compatible so if the Tuesday of the following week rolled around and for some reason we didn't want to roll forward with MCR for group1 we could reset group0 to the non MCR branch and continue the train as normal without MCR or do another train week similar to the above.
This could also be done for multiple weeks.
I think this is a reasonable plan as long as our tooling doesn't barf on the odd name :). I suppose that means we'd like to do this next week?
That depends on how the review goes etc, I'll keep you updated
If the tooling does barf because of the odd name we could always switch it to something odd such as wmf.011011010110001101110010? (mcr in binary)?
The patches will be:
The plan is that the patches will be merged into master during EU morning time tomorrow (14th)
Testing on the beta cluster will follow throughout the EU day time.
In the evening of the 14th we will attempt a new branch with these 3 MCR patches for group0.
That branch will remain on group0 for 14th-25th
On the 25th / 26th the success can be determined and the code will probably continue on the train that week in the next branch.
When we merge the code we will ping ops@ and wikitech-l@ mailing lists.
I think there are a few places (https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/master/scap/plugins/prep.py#20 being the one I can find most readily) that expect essentially what that regex is expecting. That is: https://regex101.com/r/b0Tn8X/1
Mentioned in SAL (#wikimedia-operations) [2018-06-14T20:12:27Z] <thcipriani@deploy1001> Started scap: testwiki to 1.32.0-wmf.999 (multi-content-revisions T196585) and rebuild l10n cache
Mentioned in SAL (#wikimedia-operations) [2018-06-14T21:18:17Z] <thcipriani@deploy1001> Finished scap: testwiki to 1.32.0-wmf.999 (multi-content-revisions T196585) and rebuild l10n cache (duration: 65m 50s)
Change 440476 had a related patch set uploaded (by Thcipriani; owner: Thcipriani):
[operations/mediawiki-config@master] Group0 to 1.32.0-wmf.999
Change 440476 merged by jenkins-bot:
[operations/mediawiki-config@master] Group0 to 1.32.0-wmf.999
Mentioned in SAL (#wikimedia-operations) [2018-06-14T21:47:52Z] <thcipriani@deploy1001> rebuilt and synchronized wikiversions files: group0 to 1.32.0-wmf.999 T196585
Going to mark this as resolved as our lovely .999 branch with the main current MCR patches is on group0 now and has been since last night.