725089 - "Current Performance and Availability Status" Does Not Include FTP Download Sites

Status: RESOLVED WONTFIX

(mozilla.org Graveyard :: Server Operations, task)

Description

[David E. Ross]

The page at <http://status.mozilla.com/> does not list releases.mozilla.org.  Yes, I know this is an FTP site and not a Web site.  I also know there are several mirror sites (11 currently) with the same domain name.  For some users (me included), this is the source from which we download new releases.  

A fix should include all mirrors.  If one is down, a user could then select a different one.  

I am not the only user affected.  This was a thread (Subject: cannot connect to releases.mozilla.org using FTP) in the mozilla.support.thunderbird newsgroup, started by another user.  See <news://news.mozilla.org:119/[e-mail]>.

Comment 1

[Reed Loden [:reed]]

Then you should file tickets about problems with releases.mozilla.org... mozilla.org :: FTP Mirrors is the right place.

Comment 2

[David E. Ross]

At the moment, the problem is NOT with releases.mozilla.org itself.  It is with the failure to show status for that server at <http://status.mozilla.com/>.

Comment 3

[Dave Miller [:justdave]]

Mirrors that are dead are automatically pulled from the DNS pool.  This should never be down unless we lose all 11 of them.

Comment 4

[David E. Ross]

There have been occasions when my FTP client times-out trying to connect to releases.mozilla.org.  Retrying the connection often gives the same result.  (But it is NOT happening right now.)  My client has a 65 second time-out setting.  

If one of the mirrors is slow or very busy, it does not mean the particular server is down; but the Status page should indicate that there is some kind of impairment, also indicating the affected IP address.  I would then attempt to connect while using the IP address of a different mirror.

Comment 5

[Dave Miller [:justdave]]

We have https://nagios.mozilla.org/ftplag/ (use guest/guest) to log in.  It's possible we might be able to get that data into some form that the status page can read, I suppose.  Not quite sure how to do it though.

Comment 6

[Rick Bryce [:rbryce]]

Getting releases.mozilla.org added to status.mozilla.org used to be a huge messy task with nimsoft's Watchmouse.  Just getting a user account was painful.  Now that CA has purchased Watchmouse, this task is alot more sane.  Only issue now, is we are out of out allotted monitoring slots (30).  Bug 854949 for more watchmouse monitors.

Comment 7

[Jake Maul [:jakem]]

We can't feasibly put releases.mozilla.org into watchmouse at this precise moment. It's several distinct / independent nodes served up in a DNS-Round-Robin fashion (more or less). Effective watchmouse monitoring would mean watching all of them individually.

Bug 850584 is relevant here... that'll simplify releases.mozilla.org enough to make this more feasible.


A more significant concern is, who and what is still relying on releases.mozilla.org? That's not how we do product delivery anymore, and nothing critical should be depending on this. If something is relying on it, we need to change it.

... but now that I've said all that, I recognize that this bug is actually rather old and only just now popping back up (presumably found in a triage session).

Comment 8

[David E. Ross]

At the time I submitted this bug report, I was using releases.mozilla.org as the domain in an FTP application for downloading the installer files for major end-user releases and occasional beta releases and for downloading .mar files for incremental minor end-user releases.  

I am now using ftp.mozilla.org in the FTP application.  The status of this too should be reported at <http://status.mozilla.com/>, which only lists that domain as an HTTP site and not as an FTP site.  I have updated the Summary accordingly.

Comment 9

[Rick Bryce [:rbryce]]

> ... but now that I've said all that, I recognize that this bug is actually
> rather old and only just now popping back up (presumably found in a triage
> session).

This got pushed to the back burner because the old nimsoft interface and docs, made changing the status page next to impossible.  Recent upgrades (company being bought-out) have changed this.  I just added blog.m.o to the status page, and it prompted me to revisit this.

Comment 10

[Rick Bryce [:rbryce]]

Bug 854949 was a wontfixed. Which means the same for this bug.

Comment 11

[David E. Ross]

Given that both bug #727262 and bug #854949 have "Access Denied", some explanation is required here of why they block this bug and why their WontFix status also makes this a WontFix.

Comment 12

[Jake Maul [:jakem]]

Sorry about that!

The takeaway from bug 854949 is that we are intending to deprecate this service (Nimsoft, previously known as Watchmouse), in favor of one of 2 alternate possible solutions we are still investigating. Because of this, we have no plans to purchase additional monitoring licenses in Nimsoft that would enable us to add more services to this system.

We can *replace* something that's already there, if we can make a good case for ftp://ftp.mozilla.org as being more important. However since this is not involved in the product delivery pipeline (http:// is), nor is it part of any other official workflow that I'm aware of, I suspect that would be a hard sell. It's a service we offer simply because we have historically offered it and some people rely on it, but we no longer depend on it, so we don't consider it a critical service (ftp://ftp.mozilla.org, that is... http:// is very critical).