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-05-17 19:39:45 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
|
|
|
use lockapi;
|
|
|
|
use mmapi;
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
2018-10-06 06:53:17 +00:00
|
|
|
# make sure ipa.service actually came up successfully
|
|
|
|
my $count = 40;
|
|
|
|
while (1) {
|
|
|
|
$count -= 1;
|
|
|
|
die "Waited too long for ipa.service to show up!" if ($count == 0);
|
|
|
|
sleep 3;
|
|
|
|
# if it's active, we're done here
|
|
|
|
last unless script_run 'systemctl is-active ipa.service';
|
|
|
|
# if it's not...fail if it's failed
|
|
|
|
assert_script_run '! systemctl is-failed ipa.service';
|
|
|
|
# if we get here, it's activating, so loop around
|
|
|
|
}
|
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-05-17 19:39:45 +00:00
|
|
|
# if this is an update, notify clients that we're now up again
|
|
|
|
mutex_create('server_upgraded') if get_var("UPGRADE");
|
2020-01-10 22:25:45 +00:00
|
|
|
# once child jobs are done, stop the server
|
|
|
|
wait_for_children;
|
|
|
|
# run post-fail hook to upload logs - even when this test passes
|
|
|
|
# there are often cases where we need to see the logs (e.g. client
|
|
|
|
# test failed due to server issue)
|
|
|
|
$self->post_fail_hook();
|
2022-06-23 00:51:04 +00:00
|
|
|
# FIXME as of 2022-06-22, this is taking longer than expected on
|
|
|
|
# Rawhide due to RHBZ #2100282 . It's hard to do 'soft fail if
|
|
|
|
# this takes too long', so let's just give it more time
|
|
|
|
assert_script_run 'systemctl stop ipa.service', 120;
|
2020-01-10 22:25:45 +00:00
|
|
|
# check server is stopped
|
|
|
|
assert_script_run '! systemctl is-active ipa.service';
|
|
|
|
# decommission the server
|
|
|
|
assert_script_run 'ipa-server-install -U --uninstall', 300;
|
|
|
|
# try and un-garble the screen that the above sometimes garbles
|
|
|
|
# ...we may be on tty1 or tty3 now, so flip between them
|
2024-01-09 18:37:57 +00:00
|
|
|
select_console "tty1-console";
|
|
|
|
select_console "tty3-console";
|
2020-01-10 22:25:45 +00:00
|
|
|
# FIXME check server is decommissioned...how?
|
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-05-17 19:39:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
2022-07-28 20:32:57 +00:00
|
|
|
return {fatal => 1};
|
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-05-17 19:39:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|