Closed Bug 475145 Opened 13 years ago Closed 13 years ago

Make throttling possible per-product, per-version

Categories

(AUS Graveyard :: Administration, task, P2)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: morgamic, Assigned: morgamic)

Details

(Keywords: fixed1.9.1)

Attachments

(1 file)

Throttling needs to be configurable so it's possible to make a specific product/version throttled but not the entire app update service.
It'd also be useful to be able to throttle per channel.
Morgamic: what's the size of the work required, here?

I'd like to consider this as blocking Firefox 3.1, as it would allow Firefox 3.0 users to get the major update to Firefox 3.1 at launch date if we:

 - publish major update MARs for 3.0.x -> 3.1 on launch day
 - put the major update snippets on the 3.0.x RELEASE channel
 - throttle that channel (and that channel only) to 100% so that only people who Check for Updates... get the MU offer
Flags: blocking-firefox3.1?
Couple days, few days at most including testing.  It'll be done by Feb 20.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
gentle ping - any update ?
Done my March 23rd or I'm fired.
* not really
Taking a look at this, the quickest path to victory is to provide a simple config array similar to the branchVersions array that contains values for throttling.  I am going to make this granular down to channel only.
That said, I am still going to preserve a way to make throttling global.  THROTTLE_LEVEL and THROTTLE will still apply globally but won't override the explicit throttling options defined by the config array.
Attached patch v1, first crackSplinter Review
First attempt at patch.  Notes:
* kept with procedural nature of index.php... nothing special
* added config-test.php for use with testing (instead of hacky commented-out config-dist.php)
* added config array to config-dist.php for product/version/channel throttling
* global still works, but explicit throttling overrides it
Attachment #369015 - Flags: review?(oremj)
Jeremy, if you have any time could you take a look at this patch?  If you don't, let me know and I'll find someone else.
Comment on attachment 369015 [details] [diff] [review]
v1, first crack

Looks good to me.
Attachment #369015 - Flags: review?(oremj) → review+
Comment on attachment 369015 [details] [diff] [review]
v1, first crack

>+// The Initial Developer of the Original Code is Mike Morgan.

If this is a new file, this should probably be "Mozilla Corporation", fyi. That is, unless you originally wrote AUS while not employed by MoCo/MoFo.
Comment on attachment 369015 [details] [diff] [review]
v1, first crack

Reed, could you look over this patch as well?
Attachment #369015 - Flags: review?(reed)
Attachment #369015 - Flags: review?(reed) → review?(clouserw)
Comment on attachment 369015 [details] [diff] [review]
v1, first crack

s/reed/clouserw/
Comment on attachment 369015 [details] [diff] [review]
v1, first crack

Works in my tests but my testing URL is pretty old.  It would be nice to have new examples on the wiki.
Attachment #369015 - Flags: review?(clouserw) → review+
Pushed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Morgamic, do we need to push this to 1.9.1?
Not clear what you're asking.  It's out there in production already so if anybody needs to use it, it's a config change.
AUS only lives in CVS, so it doesn't need to land in hg:mozilla-1.9.1 or central.
I'm guessing that he's asking "can we mark this fixed1.9.1 so that it doesn't show up on the list of unfixed Firefox 3.5 blockers" :) Sounds like we can!
Keywords: fixed1.9.1
(In reply to comment #20)
> I'm guessing that he's asking "can we mark this fixed1.9.1 so that it doesn't
> show up on the list of unfixed Firefox 3.5 blockers" :) Sounds like we can!

That is *exactly* what I'm asking.  :)
You need to log in before you can comment on or make changes to this bug.