teach the Balrog Agent how to look for and enact changes to Releases, Permissions, and Required Signoffs

RESOLVED FIXED

Status

Release Engineering
Balrog: Backend
P1
normal
RESOLVED FIXED
a year ago
7 months ago

People

(Reporter: bhearsum, Assigned: vjoshi)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=python][ready])

Comment hidden (empty)
(Reporter)

Updated

a year ago
No longer blocks: 1310188
Depends on: 1310188
(Reporter)

Updated

a year ago
No longer blocks: 1310210
Depends on: 1310210
(Reporter)

Updated

a year ago
Blocks: 1278974
(Reporter)

Comment 1

10 months ago
Varun is planning to look at this.
Assignee: nobody → varunj.1011
(Reporter)

Updated

9 months ago
Priority: -- → P1
Whiteboard: [lang=python][ready]

Comment 2

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

https://github.com/mozilla/balrog/commit/eda43c6605f71ef5f23d9bca5c670f3f2d44f8c8
bug 1310217: Make Agent Aware of Release and Permissions Scheduled Changes (#214). r=bhearsum
(Reporter)

Updated

9 months ago
Depends on: 1335427
(Reporter)

Comment 3

9 months ago
I discovered a bug this morning - if there are multiple pending scheduled changes for one endpoint, only the first one will be enacted. I think this is because "endpoint" gets re-used for each iteration of the inner loop of run_agent, and we end up making requests like:
balrogadmin_1  | [pid: 13|app: 0|req: 7/7] 172.17.0.6 () {42 vars in 733 bytes} [Tue Jan 31 18:22:42 2017] POST /api/scheduled_changes//scheduled_changes/permissions/5/enact/7/enact => generated 233 bytes in 8 msecs (HTTP/1.1 404) 4 headers in 128 bytes (1 switches on core 0)


Can you fix that, Varun?
Flags: needinfo?(varunj.1011)
(Reporter)

Comment 4

9 months ago
The first part of this is in production - we still need to support Required Signoffs, which is blocked on having API methods for that.
(Reporter)

Comment 5

8 months ago
(In reply to Ben Hearsum (:bhearsum) from comment #3)
> I discovered a bug this morning - if there are multiple pending scheduled
> changes for one endpoint, only the first one will be enacted. I think this
> is because "endpoint" gets re-used for each iteration of the inner loop of
> run_agent, and we end up making requests like:
> balrogadmin_1  | [pid: 13|app: 0|req: 7/7] 172.17.0.6 () {42 vars in 733
> bytes} [Tue Jan 31 18:22:42 2017] POST
> /api/scheduled_changes//scheduled_changes/permissions/5/enact/7/enact =>
> generated 233 bytes in 8 msecs (HTTP/1.1 404) 4 headers in 128 bytes (1
> switches on core 0)
> 
> 
> Can you fix that, Varun?

This was fixed awhile ago.
Flags: needinfo?(varunj.1011)
(Reporter)

Comment 6

8 months ago
Varun, will you be able to look at the Required Signoffs part of this soon? https://github.com/mozilla/balrog/pull/218 should have the necessary information, and I expect it to merge to master next week.
Flags: needinfo?(varunj.1011)
Summary: teach the Balrog Agent how to look for and enact changes to Releases, Permissions, and Required Roles → teach the Balrog Agent how to look for and enact changes to Releases, Permissions, and Required Signoffs

Comment 7

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

https://github.com/mozilla/balrog/commit/ebbaffe5d47bf7a52735898cf460da751119a842
Bug 1310217 - teach the Balrog Agent how to look for and enact Required Signoffs (#261). r=bhearsum
(Reporter)

Updated

8 months ago
Depends on: 1345586
(Reporter)

Comment 8

7 months ago
Thanks for this Varun!
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Flags: needinfo?(varunj.1011)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.