On Sun, Jul 19, 2020 at 08:53:17PM +0200, Slávek Banko wrote:
I read this thread a few minutes ago. I really like
the short address
- if such an address
can be considered stable (it was mentioned that it is testing), I
would prefer. to use this URL.
This address is stable and uses the load balancer. In just under one
week from now it'll also support https - we're just waiting until Let's
Encrypt will let us have more certificates :-)
On Sun, Jul 19, 2020 at 12:20:47PM -0700, Mike Bird wrote:
Copernicus is currently rebuilding but even before
that there were
often distinct differences, e.g. 2461 files difference between kuiper
and copernicus during primary mirror's daily report on June 9th:
> 0 files missing from copernicus.mirrorservice.org::trinitydesktop.org/
> 2461 files missing from kuiper.mirrorservice.org::trinitydesktop.org/
Copernicus is now back online. If you see issues like this in the future
please get in touch and I'll investigate. Unless the files are very
fresh (we sync every 6 hours - happy to change that if needed) this
On Mon, Jul 20, 2020 at 09:38:41AM +0200, Slávek Banko wrote:
On Monday 20 of July 2020 02:40:48 Mike Bird wrote:
On Sun July 19 2020 17:12:12 Slávek Banko wrote:
The ideal solution would probably be to add the
"base URL" and
"backend URLs" option to the mirror configuration. A "base URL"
be used for address listing and redirection. To test the usability of
the mirror, all available "backend URLs" would then be tested and the
overall status of the mirror would be determined by whether at least
one "backend URL" is accessible and at the same time whether all of
the accessible "backend URLs" are updated.
Maybe some kind of "partial" status on the web page if some but not all
backends are up?
For use in the redirector, it will be important if all accessible backends
are updated - ie "green" status. If any of the backends is inaccessible,
this is not an obstacle for use with the redirector.
For detailed information suitable for diagnostics, in addition to the
summary status, the status of individual backends could also be listed
there. Instead of the summary "partial", a real state could be seen.
For information, the redirector uses a special page mode to find usable
mirrors, where it gets a plain list of usable urls - mirrors that are not
ready are not listed:
A solution that probed the backends and sent users to the load balanced
address when the files were present on both mirrors would be fine.
Although this does mean effectively not using our service if one backend
has issues, but if you have other mirrors that's not really a problem.
I'd also be happy with a solution that meant you weren't publicising or
directly giving users the backend addresses. If you have your own
redirector that can effectively perform the same, or better, job as our
load balancer then I'm fine with that, even if it primarily always
selects the same backend. Since you're a relatively low traffic mirror
I'm more concerned about availability rather than spreading load - I
feel bad whenever users are affected by avoidable downtime, such as
patching or hardware maintenance.
I suppose an ideal solution would combine the two; using the load
balanced address when both backends have the files, but falling back to
a single one in a case where only one has the files. That's likely
heading in to the real of unnecessary effort though :-)
Computing Officer, School of Computing, University of Kent.
PGP Key: 0x6C226B37FDF38D55
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: