When talking about https://bugzilla.redhat.com/show_bug.cgi?id=1879127 , @adamwill mentioned that OpenQA currently tests base URL repos and mirrorlist repos in Anaconda, but it doesn't test metalinks. This is a request to test metalinks as well, so that we can avoid regressions like the bug linked above.
I don't know what external repos testing is currently implemented. But if you have a directory somewhere with some extra package and use it for external repo testing, you can easily create both a mirrorlist and a metalink, which will point to the same repository. Those can be static files which don't need to change (as long as the repo stays in the same location). So it could be trivial to extend the current existing tests with a metalink test.
We don't bother using external repos for this purpose, we just use the official ones. It would be pretty trivial to add a test that explicitly enters the correct official metalink URL similar to the one that enters the correct official mirrorlist URL, I think.
The only issue we have with using metalinks is it can get a bit flaky if it happens to hit a very slow server to get the metadata. But that's kinda unavoidable. It's probably worth adding the test anyway.
If the test runs inside Fedora Infra, the MirrorManager should always return the internal repo as the one with the highest priority. If it doesn't happen, it's a bug in MM. At least that's how it worked in Taskotron deployments, IIRC.
But if you only use official repositories, how do you verify that the repo actually got used and that it wasn't just a no-op? One option is to use updates-testing, but I'm not exactly clear on that full life-cycle here (Is it available always? Certainly not on Rawhide. Does anaconda have it automatically enabled after Branching?). That's why I thought having a static external repo with a single package (which Supplements some core package, and can be easily created by rpmfluff I believe) would be helpful here. The mirrorlist and the metalink can be static files as well, and the verification can just make sure the single extra package is installed.
If the test runs inside Fedora Infra, the MirrorManager should always return the internal repo as the one with the highest priority
it does, but there's a wrinkle with metalinks - I forget the details, I'd have to go remember exactly how it works again - but basically when using a metalink dnf winds up using some random mirror, not necessarily the first in the list, to get some repo metadata from. This isn't an issue with mirrorlist because mirrorlist is simpler than metalink and doesn't do all the clever-clever stuff with checking metadata currency.
But if you only use official repositories, how do you verify that the repo actually got used and that it wasn't just a no-op?
We check the anaconda logs. It's not a perfect test, but it's quite good. The problem with your approach is that it'd have to be an additional repository, I think, which isn't the same UI or codepath as the base repository...
The problem with your approach is that it'd have to be an additional repository, I think, which isn't the same UI or codepath as the base repository...
Oh I thought we were discussing additional repositories :-) But you're right that it's a separate test case from testing metalink as a base repository, and both things are worth testing (separately).
but basically when using a metalink dnf winds up using some random mirror, not necessarily the first in the list
That still feels like a bug, if it happens. But I agree that this can be quite frustrating, especially when it happens randomly and occasionally. It was one of the reasons why we tried to stay away from MM and use baseurls in Taskotron. That's why I suggested creating a static metalink file, but that obviously only works for additional static repos. We could also do some magic with retrieving the metalink first, replacing all repos with just the primary one, and then serving that metalink ourselves, but that's obviously quite a complication :-/
We don't currently test additional repos during install at all IIRC...
I'm working on this. Sorry for the delay :)
Metadata Update from @adamwill: - Issue assigned to adamwill
This was done a while ago.
Metadata Update from @adamwill: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.