1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-24 14:53:09 +00:00
Commit Graph

11 Commits

Author SHA1 Message Date
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson
b203f41f55 Give systemctl stop ipa.service longer due to RHBZ #2100282
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-06-22 17:51:04 -07:00
Adam Williamson
fec49f05ec Drop old rolekit code from database and freeipa tests
RIP rolekit

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-10 14:25:45 -08:00
Adam Williamson
6e262be28b Add a check that FreeIPA is actually up after upgrade
The FreeIPA upgrade test didn't actually check that FreeIPA is
actually running after the upgrade and reboot, it just kinda
assumed it is. Let's add a check to the start of the 'check'
test module that makes sure ipa.service actually comes up to
'active' state. This'll make it clearer when tests are failing
because FreeIPA didn't come up right after the upgrade. The
check will run on non-upgrade tests too, but that's fine.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-05 23:53:17 -07:00
Adam Williamson
d2d6bfa695 Try something different for screen corruption after IPA uninstall
There's this annoying problem where the screen sometimes goes
messed up after ipa-server-uninstall. 'clear' doesn't seem to
really work to fix it up either. Let's try flipping between
ttys. I don't like this much as it's already a pain trying to
work out / remember what tty we might possibly be on at any
given time, but I think we're always on either 1 or 3 here, so
let's do ctrl-alt-f1 ctrl-alt-f3 to ensure at least one change
and wind up on tty3...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-28 18:09:58 -07:00
Adam Williamson
cfe2a33038 Have domain controller upload logs *before* decommissioning
It transpires that decommissioning wipes some stuff, like the
dirsrv logs. Obviously we want these included in the logs we
upload for reference purposes, so let's upload earlier.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-08-24 14:42:52 -07:00
Adam Williamson
9df64398ee Add a FreeIPA replication job set
This adds a set of jobs to test FreeIPA replication. We deploy
a server, deploy a replica of that server, then enrol a client
against the replica and run the client tests.

At first I was planning to add the replica testing into the
main set of FreeIPA tests, but the test ordering/blocking (via
mutexes and barriers and what-have-you) just turns into a big
nightmare that way. This way seems rather simpler to deal with.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-08-02 09:59:40 -07:00
Adam Williamson
5999058d07 We should *not* check CURRREL for rolekit in _check
...because by this point in the upgrade test, the system is
upgraded, and rolekit won't be there on F29+.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-10 16:21:54 -07:00
Adam Williamson
7e7016ea14 Convert domain controller test not to use rolekit
Rolekit is going away. At least for the F29 cycle, though, we
still want to test basically the same functionality. This ports
the 'domain controller role' test to use ipa-server-install
directly rather than rolectl.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-09 19:54:49 -07:00
Adam Williamson
60913a20e0 Always upload logs at end of domain_controller test
We often want to see the logs from the FreeIPA deployment test
even if that test passes - to look for some detail that doesn't
cause a test to fail, for instance, or if one of the *client*
tests failed for a reason that involves the server. So, let's
do that.
2017-09-05 09:32:33 -07:00
Adam Williamson
df2c3cd906 Test upgrade of FreeIPA server and client deployment
Summary:
This adds an upgrade variant of the FreeIPA tests, with only
the simplest client enrolment (sssd) for now. The server test
starts from the N-1 release and deploys the domain controller
role. The client test similarly starts from the N-1 release
and, when the server is deployed, enrols as a domain client.
Then the server upgrades itself, while the client waits (as the
server is its name server). Then the client upgrades itself,
while the server does some self-checks. The server then waits
for the client to do its checks before decommissioning itself,
as usual. So, summary: *deployment* of both server and client
occurs on N-1, then both are upgraded, then the actual *checks*
occur on N.

In my testing, this all more or less works, except the role
decommission step fails. This failure seems to be a genuine one
so far as I can tell; I intend to file a bug for it soon.

Test Plan:
Run the new tests, check they work. Run the existing
FreeIPA tests (both the compose and the update variants), check
they both behave the same.

Reviewers: jsedlak, jskladan

Reviewed By: jsedlak

Subscribers: tflink

Differential Revision: https://phab.qa.fedoraproject.org/D1204
2017-06-02 12:17:07 -07:00