With python3-dns-2.1.0-0.1.rc1.fc34 in Fedora Rawhide I cannot deploy FreeIPA replica anymore. If I'd downgrade the package to python3-dns-2.0.0-1.fc33 version, then replica installation proceeds. Please see all the details, including dnspython's stactrace at https://pagure.io/freeipa/issue/8599
This midly violates Fedora Server basic release criteria: https://fedoraproject.org/wiki/Basic_Release_Criteria#FreeIPA_server_requirements "mildly" because this scenario is about replica deployment, not initial server. However, basic release criteria for FreeIPA server does not make difference between types of FreeIPA servers, so I consider it applying here.
I found an easy reproducer for this bug without FreeIPA being involved. It is dnspython issue with infinite loop in `Query.resolve_chaining`. All details are in the upstream ticket.
Thank you, Alex! Would it be possible to test this functionality in the FreeIPA tests in RPM build? I always try to rebuild all dependant packages during an update (especially when it's a release candidate). It should be, of course, tested in dns tests itself.
There are few aspects here. 1. In Fedora we do have already comprehensive tests in OpenQA that also test replica deployment. They run on each Bodhi request for a set of packages submitted to released branches. We can add python-dns to the list to trigger tests on its update. 2. For Rawhide, the same set of tests is run for each successful compose. Sadly, there wasn't successful run this week for different reasons, we didn't even get to replica installation: https://openqa.fedoraproject.org/tests/727806#dependencies. I am yet to find why -- my local Rawhide VMs are OK once I downgraded python3-dns to F33 version. 3. For continuous testing upstream, we already have a weekly rawhide test, scheduled similar to https://github.com/freeipa-pr-ci2/freeipa/pull/544, this one failed due to network connectivity issues.
Lumir, while upstream decides what to do with the whole CNAME processing, could you please add as a downstream patch the workaround I outlined in https://github.com/rthalley/dnspython/issues/610#issuecomment-734704756 ? It allows ipa-replica-install to proceed further and successfully get deployed.
The workaround you've proposed is included in the latest build: https://koji.fedoraproject.org/koji/taskinfo?taskID=56318506 I've verified it using the reproducer from the upstream issue.
Thanks! Let's see how it goes with the next Rawhide compose testing.
openQA didn't get to the test in the most recent compose because it runs after the "default install and upload" test, and that failed on a software selection check. Either there's a bug in software selection or anaconda/dnf changed the text written to a log file that the test checks for. I will look into that and sort it out, I didn't get to it yet as I was working on other stuff.
OK, I fixed that issue in the openQA tests, so we should be able to see where they stand shortly.
openQA is hitting https://bugzilla.redhat.com/show_bug.cgi?id=1902811 in both regular and replica tests, so we don't reach this, I don't think.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Can we close this bug? I think that the issue is fixed.
Yes. closing it.