The default bug view has changed. See this FAQ.

allow multifile updates that point directly to blobs instead of product names

RESOLVED FIXED

Status

Release Engineering
Balrog: Backend
RESOLVED FIXED
9 months ago
5 months ago

People

(Reporter: bhearsum, Assigned: ninad101)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 months ago
The current multifile update system was designed for GMP with the assumption that it would also work for System Addons. Unfortunately, now that System Addons want to have a revision number that is unique (and increasing) for each set of things we ship, it won't work very well. Because the revision is a property of the set, it must live on the superblob. However, the current superblob only points at product names, and Balrog re-parses the rules table for each of those before ending up with blobs. This means that the current superblob doesn't have enough information to effectively increment the revision number.

Rail and I did some brainstorming about this, and realized that if we had a superblob that pointed at complete release blobs instead of product names, we'd be able to have revision numbers while still putting addon-specific information in their own blobs.

Building on the examples from bug 1281347, things would look something like this:
Releases:
* Loop-1.0
* Loop-2.0
* Pocket-1.0
* SystemAddons-Rev5
** Points at Loop-1.0 and Pocket-1.0
* SystemAddons-Rev6
** Points at Loop-2.0 and Pocket-1.0
* SystemAddons-Rev7
** Points at Loop-1.0 and Pocket-1.0
* SystemAddonsRev8
** Points at Loop-1.0 and Pocket-2.0

We'd just need one rule per version to manage the System Addons. When we ship Loop 1.0 and Pocket 1.0, we'd use:
product: SystemAddons, version: 45.0, channel: release, mapping: SystemAddons-Rev5, rate: 100%

When we want to start rolling out Loop 2.0, we'd use:
product: SystemAddons, version: 45.0, channel: release, mapping: SystemAddons-Rev6, rate: 10%

If we discover a problem and want to revert back to Loop 1.0:
product: SystemAddons, version: 45.0, channel: release, mapping: SystemAddons-Rev7, rate: 100%

And if we want to fully ship Pocket-2.0 afterwards:
product: SystemAddons, version: 45.0, channel: release, mapping: SystemAddons-Rev8, rate: 100%
(Reporter)

Comment 1

6 months ago
Ninad, I'm assigning this to you per our IRC conversation. I should have some time tomorrow to chat a bit more about the implementation.
Assignee: nobody → bhat.ninadmb
(Reporter)

Comment 2

6 months ago
Robert, did we decide where in the XML the revision number would be?
Flags: needinfo?(rhelmer)
(In reply to Ben Hearsum (:bhearsum) from comment #2)
> Robert, did we decide where in the XML the revision number would be?

What I have been coding against is revision as an attribute on the addons element:

<updates>
    <addons revision="123">
    </addons>
</updates>
Flags: needinfo?(rhelmer)
(Reporter)

Comment 4

6 months ago
(In reply to Robert Helmer [:rhelmer] from comment #3)
> (In reply to Ben Hearsum (:bhearsum) from comment #2)
> > Robert, did we decide where in the XML the revision number would be?
> 
> What I have been coding against is revision as an attribute on the addons
> element:
> 
> <updates>
>     <addons revision="123">
>     </addons>
> </updates>

Hm, while reviewing Ninad's initial work on this I realized that things would be a lot simpler on the server side if we made revision an attribute of the updates elment (eg: <updates revision="123">). Would that still work for the client?
Flags: needinfo?(rhelmer)
(In reply to Ben Hearsum (:bhearsum) from comment #4)
> (In reply to Robert Helmer [:rhelmer] from comment #3)
> > (In reply to Ben Hearsum (:bhearsum) from comment #2)
> > > Robert, did we decide where in the XML the revision number would be?
> > 
> > What I have been coding against is revision as an attribute on the addons
> > element:
> > 
> > <updates>
> >     <addons revision="123">
> >     </addons>
> > </updates>
> 
> Hm, while reviewing Ninad's initial work on this I realized that things
> would be a lot simpler on the server side if we made revision an attribute
> of the updates elment (eg: <updates revision="123">). Would that still work
> for the client?

WFM
Flags: needinfo?(rhelmer)
(Reporter)

Comment 6

6 months ago
(In reply to Robert Helmer [:rhelmer] from comment #5)
> (In reply to Ben Hearsum (:bhearsum) from comment #4)
> > (In reply to Robert Helmer [:rhelmer] from comment #3)
> > > (In reply to Ben Hearsum (:bhearsum) from comment #2)
> > > > Robert, did we decide where in the XML the revision number would be?
> > > 
> > > What I have been coding against is revision as an attribute on the addons
> > > element:
> > > 
> > > <updates>
> > >     <addons revision="123">
> > >     </addons>
> > > </updates>
> > 
> > Hm, while reviewing Ninad's initial work on this I realized that things
> > would be a lot simpler on the server side if we made revision an attribute
> > of the updates elment (eg: <updates revision="123">). Would that still work
> > for the client?
> 
> WFM

Sorry for the flipflop...can we forget I asked about this though? :). Ninad found a way to make it work nicely with <addons revision="123"> as it turns out.

Comment 7

5 months ago
Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/3ee593b89385ea9fa30f649b1f10b5a3277f4799
Bug 1282898: allow multifile updates that point directly to blobs instead of product names (#145). r=bhearsum
(Reporter)

Updated

5 months ago
Depends on: 1312772
(Reporter)

Comment 8

5 months ago
This is in production, thanks Ninad!
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.