Hi, 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 > http://trinitydesktop.mirrorservice.org/trinity/ - 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 shouldn't happen. 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" would > > > 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: > > https://www.trinitydesktop.org/mirrorstatus.php?mr 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 :-) Tim. -- Tim Bishop, Computing Officer, School of Computing, University of Kent. PGP Key: 0x6C226B37FDF38D55