937770 - Shut off updates during Nov 16 maintenance window

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect)

Description

[Hal Wine [:hwine] use NI!]

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.

Comment 1

[[e-mail] (:bhearsum)]

The e-mail thread I was involved with said "shut off updates", which is different than throttling. Can we get that clarified?

Comment 2

[Hal Wine [:hwine] use NI!]

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?

Comment 3

[[e-mail] (:bhearsum)]

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.

Comment 4

[Hal Wine [:hwine] use NI!]

Based on discussions, "shut off updates" will provide the user experience desired.

Comment 5

[u279076]

Please set QA Contact to Juan Becerra once this is ready to test as I will be on vacation Nov 15 - Dec 3.

Comment 6

[Hal Wine [:hwine] use NI!]

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.

Comment 7

[[e-mail] (:bhearsum)]

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.

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

All done here ?