Some installer bugs were recently discovered with fs.protected_regular=1
Add --setup-kra to both master and replica to exercise more codepaths.
Essentially test for https://bugzilla.redhat.com/show_bug.cgi?id=1698384

Signed-off-by: François Cami fcami@redhat.com

hmm, so, the problem I see here is that the functionality covered by the existing tests - especially the regular role_deploy_domain_controller - is what's considered release-blocking; if the test fails we've probably got a release-blocking bug.

This functionality is beyond what we block the release on, I think...so if we wind up with the test failing because of this, we don't actually know if the functionality we actually block the release on is working or not.

Perhaps we could do this only for the replica tests, since they already go a bit beyond what's strictly in the release criteria? Way to do that would be to have it conditional on an openQA variable, and set that variable in the templates for the replica test suites but not the others...

Doing it replica-only should be fine.
Another possibly is to run ipa-kra-install post install in another task on replica or master.
For simplicity purposes I think having --setup-kra only in the replica install directly is fine.

@adamwill Please wait until the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1698384 is present in a f30 build.

OK. It will need to be pushed stable, then, otherwise the tests will fail for all other updates.

@fcami ping? do you think this is still a good idea? if so can you rebase and adjust it per the discussion above? thanks!