The default bug view has changed. See this FAQ.

add ability to mark releases as read only

RESOLVED FIXED

Status

Release Engineering
Balrog: Backend
RESOLVED FIXED
2 years ago
7 months ago

People

(Reporter: bhearsum, Assigned: vjoshi, Mentored)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=python])

(Reporter)

Description

2 years ago
It would be great to be able to mark release blobs as "read only" once the automation is finished adding all of the data to them. This would help to prevent accidents (or possibly attacks) that overwrite a live release blob.

Ideally, automation accounts would have enough rights to mark things as read only, but not be able to unset it. Perhaps only the "admin" bit would let one mark something as rw again?
(Reporter)

Updated

a year ago
Mentor: bhearsum@mozilla.com
Whiteboard: [lang=python]
(Assignee)

Comment 1

a year ago
So these are the changes I think I'll need to make:
1. add a `read_only` column to the Releases table by changing db.py and create a migration for it
2. in admin/views/releases.py, add logic to view and change the read only status of the release,
3. in the same file, restrict updates and deletes via the PUT and POST methods of  SingleReleaseView and ReleaseHistoryView to releases that are marked read only.

Am I right in this evaluation?
(Reporter)

Comment 2

a year ago
(In reply to Varun Joshi from comment #1)
> So these are the changes I think I'll need to make:
> 1. add a `read_only` column to the Releases table by changing db.py and
> create a migration for it

This seems right.

> 2. in admin/views/releases.py, add logic to view and change the read only
> status of the release,

Yep.

> 3. in the same file, restrict updates and deletes via the PUT and POST
> methods of  SingleReleaseView and ReleaseHistoryView to releases that are
> marked read only.

I think this should be handled in db.py instead. read-only is a bit different than a webapp-level ACL where different users have different permissions - we want to enforce it at the lowest level possible to make sure that we don't modify a read-only release by accident. The idea is that once marked read-only, someone should need to explicitly mark it as read-write again before changes can be made.

I also want to reiterate the part in comment #0 about some accounts needing to be able to mark releases as read-only, but not be able to unset it - this is an important feature.
(Reporter)

Updated

a year ago
Assignee: nobody → varunj.1011
(Assignee)

Comment 3

a year ago
Pull request created at https://github.com/mozilla/balrog/pull/56
(Reporter)

Updated

a year ago
Blocks: 1256719

Comment 4

a year ago
Commits pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/672db22d12c2e7def03cccfda04e6b861125868c
Bug 1127875 - add ability to mark releases as read only

https://github.com/mozilla/balrog/commit/74eca6d561c7addb7b88ff60ffb1192baba8e99d
Merge pull request #56 from nurav/master

Bug 1127875 - add ability to mark releases as read only. r=bhearsum
(Reporter)

Comment 5

a year ago
I've merged the patch for the backend. I'll be testing in dev a bit before deploying to production. We still need some UI to support this, which Varun is planning to take a look at later, so we'll keep this bug open until that's done.
(Reporter)

Comment 6

a year ago
I've been unable to test this in dev due to issues with the database (upgrading the schema hangs forever). I hope to have that dealt with this week, and push it to production early next week.
(Reporter)

Comment 7

a year ago
dev db has been upgraded
(Reporter)

Comment 8

a year ago
Turns out that we don't have enough disk space to upgrade the production database. Given that, I'm going to back this out for now and re-land it after we switch to RDS, where we should have more than enough space to alter the "releases_history" table.

Comment 9

a year ago
Commits pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/3a6c1c2d3fc01a0a1dfe40851ce5f84b31fb014b
Revert "Bug 1127875 - add ability to mark releases as read only"

https://github.com/mozilla/balrog/commit/0e06be7a0f122090ba20fb472c01a48521a9765c
Merge pull request #62 from mozilla/revert-56-master

Revert "Bug 1127875 - add ability to mark releases as read only"
(Reporter)

Updated

a year ago
Depends on: 1248741
(Reporter)

Comment 10

a year ago
(In reply to Ben Hearsum (:bhearsum) from comment #8)
> Turns out that we don't have enough disk space to upgrade the production
> database. Given that, I'm going to back this out for now and re-land it
> after we switch to RDS, where we should have more than enough space to alter
> the "releases_history" table.

The DBAs ended up adding a lot of extra space to our database servers, I'm going to try relanding this.

Comment 11

a year ago
Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/4a6a1d9652612390a82a8774657fafb9a76b8bbf
bug 1127875: add ability to mark releases as read only. r=bhearsum
(Reporter)

Comment 12

a year ago
The backend part of this landed in production today. We can now mark releases as read only through the API. We still need UI for it, which Varun is looking into.

Comment 13

a year ago
Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/b7710b77ae54fe67f75cab4f203a56daf9f50bdb
bug 1127875: return data_version in response from read only state changes; pick up new read-only ui (closes #67). r=bhearsum
(Reporter)

Comment 14

a year ago
This is in production now. Thanks Varun!!
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED

Comment 15

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

https://github.com/mozilla/balrog/commit/7042fb3e14b1e7286fc6dccebdb852b31cb18619
[balrog-ui] Added view for making releases read only

bug 1127875: add ui for changing read-only state of release. r=bhearsum
You need to log in before you can comment on or make changes to this bug.