469467 - Plan/deploy update infrastructure for customized distributions

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect, P3)

Comment 1

[Kev Needham [:kev]]

As we deploy more customized builds, the administrative and resource overhead of managing updates for those builds grows. There is a need to define and deploy an update infrastructure that will allow for the management and hosting of partner update files, which includes such things as partner major updates and distribution updates. This bug is intended to be a placeholder for this project/program, and will track status moving forward.

Items for consideration will include:

- Update/MAR generation for major updates and distribution updates
- AUS3, including simplifying AUS administration
- PFS
- MAR and partner build hosting
- Determining where hosting of existing and future partner updates should occur (i.e. mirrors or dedicated infra)

Comment 2

[Kev Needham [:kev]]

This is also a follow-on to some issues raised in bug 428080, mainly what we do with the existing partner update files that are currently hosted on the mirror network (and probably shouldn't be).

Comment 3

[Chris Cooper [:coop] (he/him)]

Kev: going through triage today, how many of the above issues still need to be discussed? I don't recall us having discussions about the update side of things. 

Interestingly, signing isn't mentioned but it's one of the few things we *are* doing consistently now.

Comment 4

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 5

[Chris Cooper [:coop] (he/him)]

Kev: don't we default to using the existing release mars for partner repacks now? Is this bug still valid?

Comment 6

[Chris Cooper [:coop] (he/him)]

Kev: ping ^^?

Comment 7

[Kev Needham [:kev]]

We don't default to release mars, we fallback. Partner distros will check the channel for a specialized update and fallback to the general release if the partner-specific update does not exist. 

Distribution-specific updates are still an unknown, as we haven't done any to-date. Most likely they involve changes to AUS and the product, as distribution updates should probably be handled separately from product updates. It's still an issue, and does need some love/thought.

PFS is being managed by WebDev, so is off the table from where I sit.

Finally, a long-term hosting/archiving strategy is needed for partner distributions. Partner builds aren't something we need to mirror, and don't need to maintain full histories on, but the collections will continue to grow if we continue to use our current distribution methods. People should be aware of the potential size a release could grow to, and from there we should have a plan for hosting for something more than what we do currently (BYOB especially has the potential to generate large data stores).

Comment 8

[Chris Cooper [:coop] (he/him)]

I'm going to break this bug up into a couple of smaller bugs, since there's a bit of a laundry list in here:

1) AUS changes to support distribution-specific updates. nthomas and rhelmer are actually doing some work on AUS this quarter, so now's the time to get stuff on the roadmap. (AUS:General)

2) generate partner-specific updates, including major updates. Depends on #1 (mozilla.org:Release Engineering: Custom Builds)

3) storage solution for partner distributions. Where are they being stored right now? people.mozilla.com? (mozilla.org:Server Operations)

Comment 9

[Chris Cooper [:coop] (he/him)]

(In reply to comment #8)
> 1) AUS changes to support distribution-specific updates. nthomas and rhelmer
> are actually doing some work on AUS this quarter, so now's the time to get
> stuff on the roadmap. (AUS:General)

Bug 616548
 
> 2) generate partner-specific updates, including major updates. Depends on #1
> (mozilla.org:Release Engineering: Custom Builds)

Bug 616550

> 3) storage solution for partner distributions. Where are they being stored
> right now? people.mozilla.com? (mozilla.org:Server Operations)

Bug 616555