os-autoinst-distri-rocky-mi.../tests/role_deploy_domain_controller.pm
Adam Williamson 92d588f245 Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.

We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.

We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.

My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.

Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24

Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.

Reviewers: jskladan, jsedlak

Reviewed By: jsedlak

Subscribers: tflink

Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-02-22 11:33:32 -08:00

108 lines
5.2 KiB
Perl

use base "installedtest";
use strict;
use testapi;
use lockapi;
use mmapi;
use tapnet;
use utils;
sub run {
my $self = shift;
# login
$self->root_console();
# use compose repo, disable u-t, etc.
repo_setup();
# we need a lot of entropy for this, and we don't care how good
# it is, so let's use haveged
assert_script_run 'dnf -y install haveged', 300;
assert_script_run 'systemctl start haveged.service';
# read DNS server IPs from host's /etc/resolv.conf for passing to
# rolectl
my @forwards = get_host_dns();
# we are now gonna work around a stupid bug in rolekit. we want to
# pass it a list of ipv4 DNS forwarders and have no ipv6 DNS
# forwarders. but it won't allow you to have a dns_forwarders array
# with a "ipv4" list but no "ipv6" list, any values in the "ipv6"
# list must be contactable (so we can't use real IPv6 DNS servers
# as we have no IPv6 connectivity), and if you use an empty list
# as the "ipv6" value you often hit a weird DBus error "unable to
# guess signature from an empty list". Fortunately, rolekit doesn't
# actually check that the values in the lists are really IPv6 /
# IPv4, it just turns all the values in each list into --forwarder
# args for ipa-server-install. So we can just stuff IPv4 values
# into both lists. rolekit bug:
# https://github.com/libre-server/rolekit/issues/64
# it should be fixed relatively soon.
my $fourlist;
my $sixlist;
if (scalar @forwards == 1) {
# we've only got one server, so dupe it, best we can do
$fourlist = '["' . $forwards[0] . '"]';
$sixlist = $fourlist;
}
else {
# put the first value in the 'IPv4' list and all the others in
# the 'IPv6' list
$fourlist = '["' . shift(@forwards) . '"]';
$sixlist = '["' . join('","', @forwards) . '"]';
}
# deploy the domain controller role, specifying an admin password
# and the list of DNS server IPs as JSON via stdin. If we don't do
# this, rolectl defaults to using the root servers as forwarders
# (it does not copy the settings from resolv.conf), which give the
# public results for mirrors.fedoraproject.org, some of which
# things running in phx2 cannot reach; we must make sure the phx2
# deployments use the phx2 nameservers.
assert_script_run 'echo \'{"admin_password":"monkeys123","dns_forwarders":{"ipv4":' . $fourlist . ',"ipv6":' . $sixlist .'}}\' | rolectl deploy domaincontroller --name=domain.local --settings-stdin', 1200;
# check the role status, should be 'running'
validate_script_output 'rolectl status domaincontroller/domain.local', sub { $_ =~ m/^running/ };
# check the admin password is listed in 'settings'
validate_script_output 'rolectl settings domaincontroller/domain.local', sub {$_ =~m/dm_password = \w{5,}/ };
# sanitize the settings
assert_script_run 'rolectl sanitize domaincontroller/domain.local';
# check the password now shows as 'None'
validate_script_output 'rolectl settings domaincontroller/domain.local', sub {$_ =~ m/dm_password = None/ };
# kinit as admin
assert_script_run 'echo "monkeys123" | kinit admin';
# set up an OTP for client001 enrolment (it will enrol with a kickstart)
assert_script_run 'ipa host-add client001.domain.local --password=monkeys --force';
# create two user accounts, test1 and test2
assert_script_run 'echo "correcthorse" | ipa user-add test1 --first test --last one --password';
assert_script_run 'echo "correcthorse" | ipa user-add test2 --first test --last two --password';
# add a rule allowing access to all hosts and services
assert_script_run 'ipa hbacrule-add testrule --servicecat=all --hostcat=all';
# add test1 (but not test2) to the rule
assert_script_run 'ipa hbacrule-add-user testrule --users=test1';
# disable the default 'everyone everywhere' rule
assert_script_run 'ipa hbacrule-disable allow_all';
# allow immediate password changes (as we need to test this)
assert_script_run 'ipa pwpolicy-mod --minlife=0';
# kinit as each user and set a new password
assert_script_run 'printf "correcthorse\nbatterystaple\nbatterystaple" | kinit test1@DOMAIN.LOCAL';
assert_script_run 'printf "correcthorse\nbatterystaple\nbatterystaple" | kinit test2@DOMAIN.LOCAL';
# we're all ready for other jobs to run!
mutex_create('freeipa_ready');
wait_for_children;
# once child jobs are done, stop the role
assert_script_run 'rolectl stop domaincontroller/domain.local';
# check role is stopped
validate_script_output 'rolectl status domaincontroller/domain.local', sub { $_ =~ m/^ready-to-start/ };
# decommission the role
assert_script_run 'rolectl decommission domaincontroller/domain.local', 300;
# check role is decommissioned
validate_script_output 'rolectl list instances', sub { $_ eq "" };
}
sub test_flags {
# without anything - rollback to 'lastgood' snapshot if failed
# 'fatal' - whole test suite is in danger if this fails
# 'milestone' - after this test succeeds, update 'lastgood'
# 'important' - if this fails, set the overall state to 'fail'
return { fatal => 1 };
}
1;
# vim: set sw=4 et: