1026827 - Support /update/1/ requests

Status: RESOLVED FIXED

(Release Engineering Graveyard :: Applications: Balrog (backend), defect)

Description

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

Supposing we want to serve every Firefox update request there ever was from aus4.m.o, and not run machines behind aus2 and aus3 forever more, we'll need to handle /update/1/ requests in Balrog (we already handle 2 though 4).

Looks like we swapped to /update/2/ in bug 341190, which landed for 1.8.1. So it's in 2.0, but no backport to 1.5.

Comment 1

[[e-mail] (:bhearsum)]

We won't be blocking the initial push to the release channel on this.

Comment 2

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

Bug 360127 is relevant here, frankenfox requests to deal with.

Comment 3

[[e-mail] (:bhearsum)]

For actual /update/1 requests - these are all coming from 1.5.0.x. They don't include osVersion, so we need to watershed them through a 2.0.0.x build to pick that up. That shouldn't be too difficult assuming the underlying stuff that processes osVersion in db.py will work when the incoming osVersion is null.

We'll need to generate a 2.0.0.x blob to point them at too, we have scripts that can generate most of a blob from a releases dir or snippet directory - one of them should work.

(In reply to Nick Thomas [:nthomas] from comment #2)
> Bug 360127 is relevant here, frankenfox requests to deal with.

For these frankenfoxes, it looks like we need to handle /update/2 URLs that have 1.5.0.x versions (which is indicative of frankenfoxes AFAICT). These are essentially 2.0.0.x installs but they report the wrong version and do not include osVersion, so we need to route them through a 2.0.0.x just like 1.5.0.x. The simplest way to deal with these might be to add a special route. Eg:
app.add_url_rule('/update/2/Firefox/1.5*/<buildID>/<buildTarget>/<locale>/<channel>/update.xml')

Comment 4

[[e-mail] (:bhearsum)]

Attachment: support /update/1 requests

Pretty simple, as it turns out! The only trick was making sure osVersion is set so that underlying code doesn't hit errors.

Comment 5

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

Comment on attachment 8563420 [details] [diff] [review]
support /update/1 requests

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

lgtm. Could we just fix the test ordering so that we do testVersion1Get(), testVersion2*, testVersion3*, then testVersion4Get(); because pedantic and v1 and v2 tests are very close.

Comment 6

[[github robot]]

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

https://github.com/mozilla/balrog/commit/663808f096a8fd7c10662984c809f3cf7626cfc3
bug 1026827: Support /update/1/ requests. r=nthomas

Comment 7

[[e-mail] (:bhearsum)]

Comment on attachment 8563420 [details] [diff] [review]
support /update/1 requests

(In reply to Nick Thomas [:nthomas] from comment #5)
> Comment on attachment 8563420 [details] [diff] [review]
> support /update/1 requests
> 
> Review of attachment 8563420 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> lgtm. Could we just fix the test ordering so that we do testVersion1Get(),
> testVersion2*, testVersion3*, then testVersion4Get(); because pedantic and
> v1 and v2 tests are very close.

Done! And landed in https://github.com/mozilla/balrog/commit/663808f096a8fd7c10662984c809f3cf7626cfc3

Comment 8

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #3)
> (In reply to Nick Thomas [:nthomas] from comment #2)
> > Bug 360127 is relevant here, frankenfox requests to deal with.
> 
> For these frankenfoxes, it looks like we need to handle /update/2 URLs that
> have 1.5.0.x versions (which is indicative of frankenfoxes AFAICT). These
> are essentially 2.0.0.x installs but they report the wrong version and do
> not include osVersion, so we need to route them through a 2.0.0.x just like
> 1.5.0.x. The simplest way to deal with these might be to add a special
> route. Eg:
> app.add_url_rule('/update/2/Firefox/1.5*/<buildID>/<buildTarget>/<locale>/
> <channel>/update.xml')

Looks like we need to wait until we redirect aus2 directly to aus4 to deal with these. AFAICT zeus isn't forward these correctly right now:
curl -IL https://aus2.mozilla.org/Firefox/2.0.0.20/20080401/Linux_x86-gcc3/en-US/releasetest/Linux%202.4.20/update.xml
HTTP/1.1 302 Found
Server: Apache
X-Backend-Server: pp-app-dist05
Content-Type: text/html; charset=iso-8859-1
Date: Thu, 19 Feb 2015 21:05:54 GMT
Location: https://aus3.mozilla.org/Firefox/2.0.0.20/20080401/Linux_x86-gcc3/en-US/releasetest/Linux%202.4.20/update.xml
Transfer-Encoding: chunked
Connection: Keep-Alive
X-Cache-Info: not cacheable; response is 302 without expiry time

HTTP/1.1 404 Not Found
Server: Apache
X-Backend-Server: pp-app-dist09
Cache-Control: no-store, must-revalidate, post-check=0, pre-check=0, private
Content-Type: text/html; charset=iso-8859-1
Date: Thu, 19 Feb 2015 21:05:54 GMT
Transfer-Encoding: chunked
Connection: Keep-Alive
X-Cache-Info: caching

Comment 9

[[e-mail] (:bhearsum)]

Randonote: we should make sure we're serving a support hash type when these updates get set up. I'm planning to do this after this patch gets pushed to prod.

Comment 10

[[e-mail] (:bhearsum)]

/update/1 style requests are supported now. Eg, URLs like https://aus4.mozilla.org/update/1/Firefox/1.5.0.8/20080401/Linux_x86-gcc3/en-US/releasetest/update.xml return an update.

Update paths still need to be set-up, but I'll track that elsewhere.