941949 - Support partial updates for more than the last update for nightly and aurora

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Robert Strong (they/them - no direct email)]

The goal is to provide a smaller update download for users on these channels.

It has been suggested that the app update mechanism should just download multiple partials to update to the latest version. Pros and cons for this approach

Pros
1. smaller update download than currently for up to X number of updates where the partial update for each day is added together until the size is greater than the complete update.
2. no additional mar files on the download servers.
3. others?

Cons
1. A lot of complexity on the client side that has the potential of stranding users.
2. Multiple downloads any of which could fail.
3. AUS would need to be changed to include the partial in the update.xml for X number of updates until the size added together for each partial update is greater than the complete update.
4. A failure to update any of the partials would require downloading the complete update.
5. others?

We have created and advertised partials for more than just the previous release build and I think that would be a better solution.

Pros
1. smaller update download than currently as well as with downloading multiple partials.
2. No additional complexity of the client side.
3. If there is a failure with the implementation it should be fairly simple to fallback to the current implementation.

Cons
1. Additional partial mar files would need to be generated (can this be automated?).
2. AUS would need to be changed so the update.xml for previous updates is modified to point to the new partial update instead of removing the partial update.
3. Additional mar files on the download servers.

Note: this was implemented for release in bug 575317.

Most recent time this was brought up:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/hFdlJS-CTnQ

Comment 1

[Robert Strong (they/them - no direct email)]

BTW: I am willing to take on most if not all of this bug if it something that would be accepted.

Comment 2

[[e-mail] (:bhearsum)]

I'm sure it's more work, but bug 770995 ("Partial update generation service") would give us even better hit rates for partials without touching any of the client side updater logic. The basic idea of it is that we'd generate partial dynamically after getting X requests from build Y that need build Z. I don't know when we'd have time to look at it (or at this for that matter), but I think it might be a better solution.

Comment 3

[Robert Strong (they/them - no direct email)]

Thanks Ben! Bug 770995 isn't more work. It is for the creation of partial mars and has some implementation info for creating them. This is about creating partial mars and advertising them via AUS. I'll take a look at implementing bug 770995 and if / when that bug is fixed look at what it would take to get the info into AUS.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to Robert Strong [:rstrong] (use needinfo) from comment #3)
> Thanks Ben! Bug 770995 isn't more work. It is for the creation of partial
> mars and has some implementation info for creating them. This is about
> creating partial mars and advertising them via AUS. I'll take a look at
> implementing bug 770995 and if / when that bug is fixed look at what it
> would take to get the info into AUS.

Hrm, are we interpreting that bug the same way? My understanding of it is that it has no client-side implications at all -- it's about RelEng creating a backend system that creates a specific partial after N requests for it. Subsequent requests would then get the partial.

And as I understand it, this bug doesn't mean creating extra partials, but it does mean a schema change for the XML response from AUS -- we'd need to respond with partial MARs from the past few days rather than just the most recent one.

Does this match your understanding? If not, I'd love to chat briefly so we can get on the same page.

Comment 5

[Robert Strong (they/them - no direct email)]

As I read it it isn't quite what you are saying in comment #4

From bug 770995 comment #0
> Bug 768576 asked us to create partial updates from the N-2 release to N,
> which was a fairly painful manual process. Having a service that generates
> partials on request would make this a lot simpler.
> 
> Eg, we provide
>  * url to starting complete mar, and expected hash
>  * url to starting complete mar, and expected hash 
>  * version and channel_id to apply to partial
>  * (maybe) the cert to sign the new partial with
> which returns either the partial mar and checksum information, or  directly
> uploads to a provided location on stage.
> 
> We'd still need to create snippets and handle them etc.
> 
> This isn't quite the same as 'partials on demand' that catlee promotes,
> since that's something responsive to the number of requests for completes
> where a partial would help, but a partial generator would be a necessary
> component of that.
So, this *isn't* about partials on demand. It is to support partials on demand by adding the ability to easily create partials which could be used for this bug as well.

(In reply to Ben Hearsum [:bhearsum] from comment #4)
> it's about RelEng creating
> a backend system that creates a specific partial after N requests for it.
> Subsequent requests would then get the partial.

It is about having the ability to create partials using the strategy outlined above which could be used to automate this bug.

> And as I understand it, this bug doesn't mean creating extra partials, but
> it does mean a schema change for the XML response from AUS -- we'd need to
> respond with partial MARs from the past few days rather than just the most
> recent one.

I'm not sure if you are referring to this bug or bug 770995. For this bug additional partials would be needed (from comment #0)
(In reply to Robert Strong [:rstrong] (use needinfo) from comment #0)
> Cons
> 1. Additional partial mar files would need to be generated (can this be
> automated?).

> Does this match your understanding? If not, I'd love to chat briefly so we
> can get on the same page.
Sure!

Comment 6

[[e-mail] (:bhearsum)]

Rob and I spoke about this today. It turns out that I was confused. I thought this was about applying multiple partials sequentially, but it's actually about simply generating multiple direct partials (similar to what we do for betas and releases).

If it's ready when we do this, bug 770995 would help here. The alternative to that is to support in-line generation of multiple partials in the build system.

The other piece needed here is Balrog support for multiple partials. This is tracked in bug 797033.

Comment 7

[[e-mail] (:bhearsum)]

Marking this as P3 because it depends on a couple of things and we have no plans to start work on it soon.

Comment 8

[[e-mail] (:bhearsum)]

As far as Balrog itself goes, we have all the support we need at this time. The rest of this bug is going to be glue, probably after bug 770995 is fixed.

Comment 9

[Rail Aliiev [:rail]]

We should get multiple partials (4 days going backwards) on Nightly today.