mark releases as read only after balrog submission is complete

NEW
Assigned to

Status

defect
P3
normal
4 years ago
7 days ago

People

(Reporter: bhearsum, Assigned: asilva)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Once bug 1127875 lands, we'll have the ability mark releases as "read only" in Balrog - preventing further changes to them. This seems like a generally useful thing to do for releases that have been shipped for two reasons:
1) If we try to manually make a change to an already shipped release, we will get an error (unless read_only is unset first). This serves as a good reminder to think hard in this situation.
2) Because automation accounts won't be able to unset read_only, it makes it more difficult for an attacker that gains access to an automation account to affect real users.
++
++ from me too. It maybe easier to do this when pushing updates, since we already have a balrog script running at that point.
Priority: -- → P3
Component: Release Automation: Other → Release Automation: Updates
It's probably better to do this after submission has completed now actually - to avoid the possibility of somebody modifying it after we've run update verify.
Summary: mark releases as read only as part of postrelease → mark releases as read only after balrog submission is complete
Presumably, we'll want to have a dummy task after all the balrog tasks are done, and before update verify starts. This means that update-verify will wait until all platforms are done.
(In reply to Tom Prince [:tomprince] from comment #4)
> Presumably, we'll want to have a dummy task after all the balrog tasks are
> done, and before update verify starts. This means that update-verify will
> wait until all platforms are done.

That's a notable change; this means that Linux & Mac update verify will start later than now, since they'll block on the much slower Windows builds/repacks. I'm not sure whether or not this will increase the end to end time of the promote graph -- Windows update verify will still be the long pole, but we'll now be running ~60 update verify at once, so we may increase contention in the gecko-b-3-linux pool. This is probably an OK trade-off.
Blocks: 1478214
Bug 1482395 tracks automating whatsnew page work which is currently manual, and would need extra steps once the release is marked readonly.
See Also: → 1482395
(In reply to bhearsum@mozilla.com (back in 2019Q1) from comment #5)
> (In reply to Tom Prince [:tomprince] from comment #4)
> > Presumably, we'll want to have a dummy task after all the balrog tasks are
> > done, and before update verify starts. This means that update-verify will
> > wait until all platforms are done.
> 
> That's a notable change; this means that Linux & Mac update verify will
> start later than now, since they'll block on the much slower Windows
> builds/repacks. I'm not sure whether or not this will increase the end to
> end time of the promote graph -- Windows update verify will still be the
> long pole, but we'll now be running ~60 update verify at once, so we may
> increase contention in the gecko-b-3-linux pool. This is probably an OK
> trade-off.

update verify currently does a few things:
1) checks that MARs are correctly represented in Balrog (on test channels)
2) checks that MARs can be applied correctly

if we split these up, and have update-verify check that the MARs can be applied correctly, these could be fetched from TC artifacts directly, or from the candidates dir, and not rely on Balrog state.
Assignee: nobody → allan.tavares
You need to log in before you can comment on or make changes to this bug.