765312 - FF4 to FF9 Linux 32/64-bit users were getting 404s for complete.mars

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect)

Description

[Armen [:armenzg]]

Attachment: push Linux 32/64-bit mars to the mirrors

r+ from Standard8 and rail.

Comment 1

[Armen [:armenzg]]

-Armens-MacBook-Air:productdelivery armenzg$ svn ci -m "Bug 765312. Push FF12 updates for Linux 32/64-bit to te mirrors. r=Standard8,rail"
Sending        files/rsync/rsyncd-mozilla-releases.exclude
Transmitting file data .
Committed revision 40948.

Now we gotta wait for the file to update.

Comment 2

[Armen [:armenzg]]

On another note, we should probably file a bug to generate snippets that make Linux users to point to the latest release while win32 and mac users can step on 12.0.

In the case of Thunderbird users of Linux and Mac.

Comment 3

[u279076]

Why would we give Linux users a different update path then win32 and Mac users? I thought we decided a while back that all Firefox 4.0-9.0 users would get updated to 12.0 and all Firefox 10+ users would get updated to latest.

Comment 4

[Armen [:armenzg]]

I didn't know that the decision had been made.
Then I guess there is no follow up work to happen after this bug.

I was proposing it since there was no reason to send them to FF12 like with Windows and Mac users besides making all platforms go to the same stepping stone.

Comment 5

[Armen [:armenzg]]

Attachment: adjust comment

Comment 6

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

Did ftp.m.o fall out of bouncer for a while ? When I checked that was still showing as the uptake of 1 for linux/mac updates to 12.0.

Comment 7

[Armen [:armenzg]]

I couldn't find http://ftp.mozilla.org or http://releases.mozilla.org on bouncer admin.

Comment 8

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

ftp.m.o appears in bouncer as ftp-zlb.vips.scl3.mozilla.com.

Comment 9

[Armen [:armenzg]]

I noticed that it is only marked to serve North American region.

Let me step back, we pushed the FF12 mar files for linux 32/64-bit because we were seeing final verification fail.
To be honest I only saw http://mozilla.cdn.leaseweb.com fail. Is that part of the internal mirrors?

I have few questions
* was it a good decision what we did?
** would users have been good without pushing those extra mar files?
** would bouncer have started directing them to ftp.m.o?
* what should we do now?
** can we make bouncer to point only to ftp.m.o for those mar files?
** should we exclude mozilla.cdn.leaseweb.com?
** should we modify the exclude files to pull those mars out of the mirrors? (in case we know there is a way for them to get them)
** or are we simply good on this bug and we can close?

Sorry if these are too many questions! My knowledge is very limited in this area.

FTR I run final verification once more and I did not get any 404 results but a lot of 503 (Service temporarily not available) and 403 (Forbidden) both from http://www.mirrorservice.org. I don't seem to hit them when loading the URLs that failed.

Comment 10

[Armen [:armenzg]]

I feel that the initial purpose of this bug is completed but I don't know what else to do.

Comment 11

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

Comment on attachment 633587 [details] [diff] [review]
push Linux 32/64-bit mars to the mirrors

FWIW, this patch hasn't actually done anything because rsyncd-mozilla-prereleases.exclude still excludes the update/linux* dirs. The original problem was that http://mozilla.cdn.leaseweb.com, an volunteer CDN, is a multi-node system which was in an inconsistent state. Sentry would find the linux files on a check run and enable the mirror, then the opposite on the next run. While it was enabled final verify could hit a node without the file and fail. 

This is no longer the case so I'll revert it in bug 771457.