Per email threads, we'll throttle all updates during the bug 926597 maintenance window. This bug covers both the start and stop of 100% throttle (no updates). Throttle will happen approx 30 min before the start of the maintenance window. Restoration of throttling settings will happen after IT completes it's work, but perhaps before trees are re-opened.
The e-mail thread I was involved with said "shut off updates", which is different than throttling. Can we get that clarified?
ftr, the last wording I saw was in an email from :jakem: Additionally, in talking with Alex, we've agreed that it would be best if we simply throttle off updates for the duration. That reduces the possibility for error drastically- we already know how firefox behaves when updates are off. There simply won't be any updates offered, just like the throttled interval during a new release. Can you explain the difference between "shut off updates" vs "throttle off updates" both in terms of end user experience, and how each is implemented?
Throttling is making updates only available via a manual "check for updates". It is implemented in AUS3 through a config-dist.php change, which is written by RelEng and deployed by IT. It is implemented in Balrog/AUS4 by changing the "background rate" on most of Balrog's rules through the admin ui (done by RelEng). Shutting updates is making updates completely unavailable, even if you check manually. In AUS3 is is implemented by chmod'ing the snippets to something unreadable by Apache. It is implemented in Balrog by changing the "mapping" on most of Balrog's rules.
Based on discussions, "shut off updates" will provide the user experience desired.
Summary: Throttle updates 100% during Nov 16 maintenance window → Shut off updates during Nov 16 maintenance window
Please set QA Contact to Juan Becerra once this is ready to test as I will be on vacation Nov 15 - Dec 3.
Juan -- this will be part of the Nov 16 weekend downtime, with 2 checks needed at approx 0830 and 1530 PT. This isn't the normal sort of per release throttle where we have QA verify. (Then again, I don't believe we've ever done this procedure before, as it's "belts and suspenders" operation. FF client update code should already handle these cases -- it's just another failed connection from the client perspective.) We would likely spot check a few links to ensure it behaves as expected, following https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Updates_through_Shipping#Verifying_Throttling I'm also not sure what the action to be taken if the 0830 PT check "fails". I do not believe that would block the maintenance window. A more thorough test could be performed after the window, to ensure that ALL versions are again available for update as configured.
Hal, I documented how to shut off and re-enable updates over here: https://wiki.mozilla.org/ReleaseEngineering/How_To/Shut_off_all_updates Let me know if you have any questions.
All done here ?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.