[balrog] Add support for foregroundRate or manualRate

NEW
Unassigned

Status

Release Engineering
Balrog: Backend
P3
normal
4 years ago
5 months ago

People

(Reporter: nthomas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=python])

(Reporter)

Description

4 years ago
... for throttling user initiated requests. See also bug 733274 for renaming existing throttling.
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
mass component change
Component: General Automation → Balrog: Backend
mass priority change after component move
Priority: -- → P3
(Reporter)

Comment 3

3 years ago
This came up in the postmortem today - lmandel was in favor of having this functionality so that we could do all the prep for a release on the day before, then leave both foreground & background updates disabled until the instant we want to ship. Co-ordinating shipping with marketing/website/other changes is becoming an issue, so anything we can do to preload testing is useful. 

QA would need some way to get around the throttling to test (I jokingly suggested &reallyreallyforce=1 but there must be better ways). lmandel was OK with not offering updates for the hours or so between testing and shipping, since updating twice in close succession is not great UX.

Comment 4

10 months ago
Nick, RelMan - do you think this is still desired? It would be a good contributor bug, if so.
Flags: needinfo?(sledru)
Flags: needinfo?(lukasblakk+bugs)
Flags: needinfo?(lhenry)

Comment 5

10 months ago
I'm not sure how I got a needinfo for lsblakk in there, whoops....
Flags: needinfo?(lukasblakk+bugs)
(Reporter)

Comment 6

10 months ago
I'll leave it to Releases Management to say.
To rephrase, this bug is about the fact that a user can force the update after the push to release-cdntest (usually done the day before the release) and before we enable updates, right?

I think we should indeed have this bug implemented.
Flags: needinfo?(sledru)

Comment 8

10 months ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> To rephrase, this bug is about the fact that a user can force the update
> after the push to release-cdntest (usually done the day before the release)
> and before we enable updates, right?
> 
> I think we should indeed have this bug implemented.

Not quite. That has nothing to do with Balrog (users either pave over with a new installer, or change their channel to -cdntest). This bug would give us control over the rate at which updates are served when ?force=1 is set (
Flags: needinfo?(sledru)
What would be the use case for that? Sorry, this is pretty unclear for me now.
Flags: needinfo?(sledru)
This sounds like a nice idea to me and might give us more flexibility. I can't remember the original discussion. Can we talk about it after we ship 49? :D

Updated

9 months ago
Flags: needinfo?(lhenry)
(In reply to Sylvestre Ledru [:sylvestre] from comment #9)
> What would be the use case for that? Sorry, this is pretty unclear for me
> now.

See comment #10 - Liz said it well :). It's hard to imagine a concrete use case in advance, but we've really tried to design Balrog to handle future things we haven't yet found a use for.

Updated

5 months ago
Whiteboard: [lang=python]
You need to log in before you can comment on or make changes to this bug.