What should report_mirror check? about mirrormanager2 HOT 5 OPEN

It's basically trivial to have report_mirror send more information. But there's no point in sending it if mirrormanager isn't going to use it, and I don't know if the server side code ever existed, even before the rewrite. quick-fedora-mirror already has the file list handy and could easily collect any other information that mirrormanager might use, though mirrormanager doesn't currently accept checkins in a format that anything besides report_mirror can actually generate.

Edit:
Also, with a bit more work, quick-fedora-mirror can do enough verification on the mirrored content that it should be possible to actually trust it when it reports in. Since that would happen at the end of a mirror run and not as part of a separate run of report_mirror, an admin would have to actually work at making their mirror report incorrectly.

from mirrormanager2.

The main reason for not sending more data was to reduce the number of I/Os on the client side. We are also still transmitting the host config during each report_mirror run which is also not used besides storing it in the database.

As far as I know there was never code to handle additional information from report_mirror besides the directories. As stated above the goal was to get a status from an update as fast as possible without requiring too much I/O on the client (mirror server) side.

It should be possible to handle additional information transmitted from report_mirror, but it requires someone to write the xmlrpc side code.

from mirrormanager2.

I was wrong. The code to check what is inside a directory exists:

compare_dir()

from mirrormanager2.

... and the function is not called from anywhere. So the code inside that function has not been used for many years if ever at all.

from mirrormanager2.

I can understand the will to reduce client side IO, but they're basically going to do it all anyway when they call rsync so at least the caches should be hot. And quick-fedora-mirror will also do pretty much the same directory traversals on the client as a plain rsync call would do, except that it can actually save off the data. And if the data is handy, sending it to mirrormanager should be a relatively low cost exercise.

Anyway, it's not a big deal, especially since there's no way currently for quick-fedora-mirror to actually check in with mirrormanager besides just calling report_mirror (and doing all of that IO again).

from mirrormanager2.