Re: Coconut failures: use dl.fp.o not download.fp.o?
Please note, though, that we think that the mirror issue is a legitimate bug, either caused by dnf stack, or anaconda. Jan reported it yesterday here: https://bugzilla.redhat.com/show_bug.cgi?id=1196164 If this turns out to be true, it would also mean that OpenQA helped us uncover quite an interesting bug, which would be much harder to spot without the massive number of installations executed regularly. So there is also some value in using closest mirror as installation source. Yep, that's an interesting one for sure, and sorry, I should've been clearer: I was talking only about the tests where the actual test involves specifying a particular repository URL (via the GUI or a kickstart or on the cmdline or whatever), and we're currently using 'download.fedoraproject.org' in those URLs. OK, in that case, it completely makes sense. Moreover, I believe that using inst.repo=download.fp.o is explicitly forbidden and unsupported by anaconda (I would have to dig into past bug reports to find it). The problem is that anaconda does not resolve that once and then provide it to yum/dnf, but it uses it verbatim. Therefore that URL resolves itself on every request, potentially leading to different mirrors being used for metadata and packages, which can utterly break everything. At least that's what I remember from the past, maybe now with dnf it might work a bit differently. In any case, we should avoid using inst.repo=download.fp.o by any means. It's potentially very error-prone. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Coconut failures: use dl.fp.o not download.fp.o?
On Thu, 2015-02-26 at 04:59 -0500, Kamil Paral wrote: Several of the Coconut failures for Alpha TC5 seem to be to do with mirror issues. It might be best to have Coconut use dl.fedoraproject.org ? I'll let someone more knowledgeable respond to this, but I assume you're referring to those HTTP 404/550 issues during anaconda package download, which we see heavily on the Boston machine, and less frequently on the Brno machine. Actually a couple of the TC5 tests failed with what was apparently simply a flat-out fail of trying to use download.fp.o as the repo: the check where it switches to a console and greps /tmp/packaging.log for download.fp.o failed. When I checked it manually I found yet another Canadian mirror which is busted (has its directory layout wrong, so the download.fp.o redirection fails) - but that's not likely what Coconut was hitting, as it's in Boston, it probably hit some *other* bad mirror. So my general reaction was, it seems like we have 'some kind of mirror bug' often enough that Coconut should just use dl.fp.o directly (or perhaps a Brno mirror directly, for the Brno instance) to avoid it. This is for the repository test cases - 'HTTP cmdline', 'HTTP variation' etc - where it's actually explicitly passing a repository URL, not cases where it's using 'closest mirror'. Please note, though, that we think that the mirror issue is a legitimate bug, either caused by dnf stack, or anaconda. Jan reported it yesterday here: https://bugzilla.redhat.com/show_bug.cgi?id=1196164 If this turns out to be true, it would also mean that OpenQA helped us uncover quite an interesting bug, which would be much harder to spot without the massive number of installations executed regularly. So there is also some value in using closest mirror as installation source. Yep, that's an interesting one for sure, and sorry, I should've been clearer: I was talking only about the tests where the actual test involves specifying a particular repository URL (via the GUI or a kickstart or on the cmdline or whatever), and we're currently using 'download.fedoraproject.org' in those URLs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Coconut failures: use dl.fp.o not download.fp.o?
Several of the Coconut failures for Alpha TC5 seem to be to do with mirror issues. It might be best to have Coconut use dl.fedoraproject.org ? I'll let someone more knowledgeable respond to this, but I assume you're referring to those HTTP 404/550 issues during anaconda package download, which we see heavily on the Boston machine, and less frequently on the Brno machine. In general, yes, I think it would be worth to use a specific mirror, for several reasons. In Boston, it might be reasonable to use dl.fp.o just to ensure we use the very latest package versions (otherwise the repo we hit might be up to 2 days old). In Brno, it might be reasonable to use our local mirror, even in case it's 1-2 days old, just because of the download speedups. However, this can't be used in all test cases. If we want to test the absolutely default installation, we can't set a custom mirror. If we want to test closest mirror feature, we can't set a custom mirror. In many cases, yes, it would help either speed or reliability. Please note, though, that we think that the mirror issue is a legitimate bug, either caused by dnf stack, or anaconda. Jan reported it yesterday here: https://bugzilla.redhat.com/show_bug.cgi?id=1196164 If this turns out to be true, it would also mean that OpenQA helped us uncover quite an interesting bug, which would be much harder to spot without the massive number of installations executed regularly. So there is also some value in using closest mirror as installation source. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Coconut failures: use dl.fp.o not download.fp.o?
Several of the Coconut failures for Alpha TC5 seem to be to do with mirror issues. It might be best to have Coconut use dl.fedoraproject.org ? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
