1977383 - Define and apply a strategy for the progressive rollout of Zucchini

Status: RESOLVED FIXED

(Toolkit :: Application Update, task, P3)

Description

[Yannis Juglaret [:yannis]]

After the landing of bug 1950060 (currently under review), our updater binary will be able to apply partial mars containing patches generated by zucchini on Linux, macOS and Windows. It will still support patches in the good old bspatch format, which allows us to be quite flexible in defining our strategy to transition from bspatch to zucchini while minimizing risk.

Teams Desktop Integrations (presumably, :bytesized and :nalexander) and Release Engineering (presumably, :hneiva and :jlorenzo) should work jointly on defining this strategy. Both parties should be involved to be sure that the client-side requirements, best known to Desktop Integrations, fit with the server-side requirements, best known to Release Engineering. I'm happy to participate in the discussions too if that can help.

The questions I foresee are the following:

• Is there already a fallback to complete updates in case of zucchini partial application failures? Do we need a fallback to bspatch?
• Do we already have enough monitoring to be able to detect zucchini partial application failures, so we can control that the failure rate for these updates is similar to the one for bspatch, not higher?
• Do we want zucchini partials to be Nightly-only at first? For how long?
• Is it possible to use a Nimbus experiment for the rollout to release in order to mitigate any risk of a major update incident? Is it a good idea, or is the fallback to complete updates enough?
• Is the benefit/risk ratio in favor of using zucchini for non-staged updates as well, considering that zucchini can intentionally crash under bad conditions (similar to Rust panics) but we don't expect it to (see bug 1950062 for more details)?

Comment 1

[Yannis Juglaret [:yannis]]

These questions have been answered as follows:

• Fallback to complete updates exists and is enough.
• Monitoring exists and is a bit difficult to work with but is enough.
• Nightly-only at first, we'll ride each train intentionally if monitoring data shows good results.
• No Nimbus experiment planned. We'll rely on the fallback to complete updates.
• Zucchini everywhere, we don't want to have two formats for partials for any given release.