1256719 - mark releases as read only after balrog submission is complete

Status: NEW

(Release Engineering :: Release Automation: Updates, defect, P3)

Description

[[e-mail] (:bhearsum)]

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.

Comment 1

[Jordan Lund (:jlund)]

++

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

++ from me too. It maybe easier to do this when pushing updates, since we already have a balrog script running at that point.

Comment 3

[[e-mail] (:bhearsum)]

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.

Comment 4

[Tom Prince [:tomprince]]

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.

Comment 5

[[e-mail] (:bhearsum)]

(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.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Bug 1482395 tracks automating whatsnew page work which is currently manual, and would need extra steps once the release is marked readonly.

Comment 7

[Chris AtLee [:catlee]]

(In reply to [e-mail] (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.

Comment 8

[Allan [:asilva]]

Attachment: GitHub Pull Request

Comment 9

[Allan [:asilva]]

Attachment: 0001-Bug-1256719-mark-releases-as-read-only-after-balrog-.patch

Comment 10

[[e-mail] (:bhearsum)]

Comment on attachment 9128354 [details] [diff] [review]
0001-Bug-1256719-mark-releases-as-read-only-after-balrog-.patch

Review of attachment 9128354 [details] [diff] [review]:
-----------------------------------------------------------------

This is a good start, but we need to add `- post-balrog-dummy` to the dependencies too, to make sure we don't mark as read only until after locale submission has completed.

Ideally, we'd block update verify on this new kind, but let's save that for a follow-up (I think it'll end up being fairly complicated, so let's keep things simple for now).

Comment 11

[Allan [:asilva]]

Attachment: 0001-Bug-1256719-mark-releases-as-readonly-after-balrog-s.patch

New patch including the post-balrog-dummy dep.

Comment 12

[[e-mail] (:bhearsum)]

Comment on attachment 9147009 [details] [diff] [review]
0001-Bug-1256719-mark-releases-as-readonly-after-balrog-s.patch

We decided to punt on this until the v2 releases API is being used in production.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.