testing/os-autoinst-distri-rocky
11
0
Fork 0
mirror of https://github.com/rocky-linux/os-autoinst-distri-rocky.git synced 2024-11-15 17:51:27 +00:00
Code Issues Packages Projects Releases Wiki Activity
aa3c9f6eef
os-autoinst-distri-rocky/tests/_support_server.pm

195 lines
10 KiB
Perl
Raw Normal View History

add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
use base "installedtest";
use strict;
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
use anaconda;
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
use testapi;
use lockapi;
use mmapi;
Move all remaining utility functions into exporter modules Summary: This adds a couple of new exporter modules, renames main_common to utils (this is a better name: openSUSE's main_common is functions used in main.pm, utils is what they call their module full of miscellaneous commonly-used functions), and moves a bunch of utility functions that were previously needlessly implemented as instance methods in base classes into the exporter modules. That means we can get rid of all the annoying $self-> syntax for calling them. We get rid of `fedorabase` entirely, as it's no longer useful for anything. Other base classes keep the 'standard' methods (like `post_fail_hook`) and methods which actually need to be methods (like `root_console`, whose behaviour is different in anacondatest and installedtest). Test Plan: Do a full test suite run and check everything lines up. There should be no functional differences from before at all, this is just a re-org. Reviewers: jskladan, garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Reviewed By: garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1080
2017-01-18 07:15:44 +00:00
use tapnet;
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
use utils;
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
sub _pxe_setup {
temporary name resolution support
2022-02-19 03:13:42 +00:00
# This happens before local DNS server is running and dnf will fail. Temporarily add 8.8.8.8 to resolve.conf
assert_script_run "echo 'nameserver 8.8.8.8' >> /etc/resolv.conf";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# set up PXE server (via dnsmasq). Not used for update tests.
# don't get hung up on slow mirrors when DNFing...
repos_mirrorlist;
# create necessary dirs
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "mkdir -p /var/lib/tftpboot/rocky";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# basic tftp config
assert_script_run "printf 'enable-tftp\ntftp-root=/var/lib/tftpboot\ntftp-secure\n' >> /etc/dnsmasq.conf";
# pxe boot config
# we boot grub directly not shim on aarch64 as shim fails to boot
# with 'Synchronous Exception'
# https://bugzilla.redhat.com/show_bug.cgi?id=1592148
assert_script_run "printf 'dhcp-match=set:efi-x86_64,option:client-arch,7\ndhcp-match=set:efi-x86_64,option:client-arch,9\ndhcp-match=set:bios,option:client-arch,0\ndhcp-match=set:efi-aarch64,option:client-arch,11\ndhcp-match=set:ppc64,option:client-arch,12\ndhcp-match=set:ppc64,option:client-arch,13\ndhcp-boot=tag:efi-x86_64,\"shim.efi\"\ndhcp-boot=tag:bios,\"pxelinux.0\"\ndhcp-boot=tag:efi-aarch64,\"grubaa64.efi\"\ndhcp-boot=tag:ppc64,\"boot/grub2/powerpc-ieee1275/core.elf\"\n' >> /etc/dnsmasq.conf";
# install and configure bootloaders
my $ourversion = get_var("CURRREL");
my $testversion = get_var("RELEASE");
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "mkdir -p /var/tmp/rocky";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
my $arch = get_var("ARCH");
if ($arch eq 'x86_64') {
# x86_64: use syslinux for BIOS, grub2 with 'linuxefi' for UEFI
assert_script_run "mkdir -p /var/lib/tftpboot/pxelinux.cfg";
# install bootloader packages
assert_script_run "dnf -y install syslinux", 120;
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "rpm --root=/var/tmp/rocky --rebuilddb", 60;
assert_script_run "cd /var/tmp; dnf download rocky-release rocky-repos rocky-gpg-keys", 60;
assert_script_run "rpm --root=/var/tmp/rocky --nodeps -i /var/tmp/*.rpm", 60;
#assert_script_run "sed -i /var/tmp/rocky/etc/yum.repos.d/Rocky-*.repo -e 's/repo=/repo=rocky-/g'", 60;
extend timeouts
2022-02-19 03:12:25 +00:00
assert_script_run "dnf -y --releasever=$ourversion --refresh --installroot=/var/tmp/rocky install shim-x64 grub2-efi-x64", 1800;
update _pxe_setup
2022-02-19 03:14:47 +00:00
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# copy bootloader files to tftp root
assert_script_run "cp /usr/share/syslinux/{pxelinux.0,vesamenu.c32,ldlinux.c32,libcom32.c32,libutil.c32} /var/lib/tftpboot";
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "cp /var/tmp/rocky/boot/efi/EFI/rocky/{shimx64.efi,shimx64-rocky.efi,grubx64.efi} /var/lib/tftpboot";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# bootloader configs
# BIOS
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "printf 'default vesamenu.c32\nprompt 1\ntimeout 600\n\nlabel linux\n menu label ^Install Rocky Linux 64-bit\n menu default\n kernel rocky/vmlinuz\n append initr
d=rocky/initrd.img inst.ks=file:///ks.cfg ip=dhcp\nlabel local\n menu label Boot from ^local drive\n localboot 0xffff\n' >> /var/lib/tftpboot/pxelinux.cfg/default";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# UEFI
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "printf 'function load_video {\n insmod efi_gop\n insmod efi_uga\n insmod ieee1275_fb\n insmod vbe\n insmod vga\n insmod video_bochs\n insmod video_cirrus\n}\
n\nload_video\nset gfxpayload=keep\ninsmod gzio\n\nmenuentry \"Install Rocky Linux 64-bit\" --class rocky --class gnu-linux --class gnu --class os {\n linuxefi rocky/vmlinuz ip=dhcp inst.ks=
file:///ks.cfg\n initrdefi rocky/initrd.img\n}' >> /var/lib/tftpboot/grub.cfg";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# DEBUG DEBUG
upload_logs "/etc/dnsmasq.conf";
upload_logs "/var/lib/tftpboot/grub.cfg";
upload_logs "/var/lib/tftpboot/pxelinux.cfg/default";
}
elsif ($arch eq 'ppc64le') {
# ppc64le: use grub2 for OFW
# install bootloader tools package
extend timeouts
2022-02-19 03:12:25 +00:00
assert_script_run "dnf -y install grub2-tools-extra", 360;
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# install a network bootloader to tftp root
assert_script_run "grub2-mknetdir --net-directory=/var/lib/tftpboot";
# bootloader config
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "printf 'set default=0\nset timeout=5\n\nmenuentry \"Install Rocky Linux\" --class rocky --class gnu-linux --class gnu --class os {\n linux rocky/vmlinuz ip=dhcp inst.ks=file:///ks.cfg\n initrd rocky/initrd.img\n}' >> /var/lib/tftpboot/boot/grub2/grub.cfg";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# DEBUG DEBUG
upload_logs "/etc/dnsmasq.conf";
upload_logs "/var/lib/tftpboot/boot/grub2/grub.cfg";
}
elsif ($arch eq 'aarch64') {
# aarch64: use grub2 with 'linux' for UEFI
# copy bootloader files to tftp root (we just use the system
# bootloader, no need to install packages)
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "cp /boot/efi/EFI/rocky/{shim.efi,grubaa64.efi} /var/lib/tftpboot";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# bootloader config
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "printf 'function load_video {\n insmod efi_gop\n insmod efi_uga\n insmod ieee1275_fb\n insmod vbe\n insmod vga\n insmod video_bochs\n insmod video_cirrus\n}\n\nload_video\nset gfxpayload=keep\ninsmod gzio\n\nmenuentry \"Install Rocky Linux\" --class rocky --class gnu-linux --class gnu --class os {\n linux rocky/vmlinuz ip=dhcp inst.ks=file:///ks.cfg\n initrd rocky/initrd.img\n}' >> /var/lib/tftpboot/grub.cfg";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# DEBUG DEBUG
upload_logs "/etc/dnsmasq.conf";
upload_logs "/var/lib/tftpboot/grub.cfg";
}
# download kernel and initramfs
my $location = get_var("LOCATION");
my $kernpath = "images/pxeboot";
# for some crazy reason these are in a different place for ppc64
$kernpath = "ppc/ppc64" if ($arch eq 'ppc64le');
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "curl -o /var/lib/tftpboot/rocky/vmlinuz $location/BaseOS/${arch}/os/${kernpath}/vmlinuz";
assert_script_run "curl -o /var/lib/tftpboot/rocky/initrd.img $location/BaseOS/${arch}/os/${kernpath}/initrd.img";
Tweak PXE boot test to also check kickstart file path One of the test cases we didn't yet automate is: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg Now we have a PXE test, it's actually a good opportunity to test that at the same time. I don't usually like combining tests like this but in this case it sort of makes sense as otherwise we'd have to have a whole parallel PXE install just to test this one other detail. So, instead of doing an interactive PXE install as we did at first, let's tweak the test to include a kickstart in the initramfs and run the install from that. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-10-07 20:24:52 +00:00
# get a kickstart to embed in the initramfs, for testing:
# https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "curl -o ks.cfg https://git.rockylinux.org/tcooper/kickstarts/-/raw/main/root-user-crypted-net.ks";
Tweak PXE boot test to also check kickstart file path One of the test cases we didn't yet automate is: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg Now we have a PXE test, it's actually a good opportunity to test that at the same time. I don't usually like combining tests like this but in this case it sort of makes sense as otherwise we'd have to have a whole parallel PXE install just to test this one other detail. So, instead of doing an interactive PXE install as we did at first, let's tweak the test to include a kickstart in the initramfs and run the install from that. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-10-07 20:24:52 +00:00
# tweak the repo config in it
update _pxe_setup
2022-02-19 03:14:47 +00:00
assert_script_run "sed -i -e 's,^url.*,nfs --server=nfs://172.16.2.110 --dir=/repo --opts=nfsver=4,g' ks.cfg";
Tweak PXE boot test to also check kickstart file path One of the test cases we didn't yet automate is: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg Now we have a PXE test, it's actually a good opportunity to test that at the same time. I don't usually like combining tests like this but in this case it sort of makes sense as otherwise we'd have to have a whole parallel PXE install just to test this one other detail. So, instead of doing an interactive PXE install as we did at first, let's tweak the test to include a kickstart in the initramfs and run the install from that. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-10-07 20:24:52 +00:00
# embed it
Update the support server script for rocky
2022-01-30 21:31:48 +00:00
assert_script_run "echo ks.cfg | cpio -c -o >> /var/lib/tftpboot/rocky/initrd.img";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# chown root
assert_script_run "chown -R dnsmasq /var/lib/tftpboot";
assert_script_run "restorecon -vr /var/lib/tftpboot";
# open firewall ports
assert_script_run "firewall-cmd --add-service=tftp";
}
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
sub run {
my $self=shift;
support_server: disable systemd-resolved We're setting up our own (dnsmasq) name server, we can't have resolved running. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 16:07:46 +00:00
# disable systemd-resolved, it conflicts with dnsmasq
unless (script_run "systemctl is-active systemd-resolved.service") {
script_run "systemctl stop systemd-resolved.service";
script_run "systemctl disable systemd-resolved.service";
script_run "rm -f /etc/resolv.conf";
script_run "systemctl restart NetworkManager";
}
add NFS tests (and DHCP/DNS in the support server) Summary: Set up the support server to provide DHCP/DNS functionality and an NFS server, providing a kickstart. Add a kickstart test just like the other root-user-crypted-net kickstart tests except it gets the kickstart from the support server via NFS. Also add NFS repository tests and a second support server for Server-dvd-iso flavor: this test must run on that flavor to ensure that packages are actually available. The support server just mounts the attached 'DVD' and exports it via NFS. Note we don't need to do anything clever to avoid IP conflicts between the two support servers, because os-autoinst-openvswitch ensures each worker group is on its own VLAN. As part of adding the NFS repo tests, I did a bit of cleanup, moving little things we were repeating a lot into anacondatest, and sharing the 'check if the repo was used' logic between all the tests (by making it into a test step that's loaded for all of them). I also simplified the 'was repo used' checks a bit, it seems silly to run a 'grep' command inside the VM then have os-autoinst do a grep on the output (which is effectively what we were doing before), instead we'll just use a single grep within the VM, and clean up the messy quoting/escaping a bit. Test Plan: Run all tests - at least all repository tests - and check they work (make sure the tests are actually still sane, not just that they pass). I've done runs of all the repo tests and they look good to me, but please double-check. I'm currently re-running the whole 24-20160609.n.0 test on staging with these changes. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D888
2016-06-13 15:42:30 +00:00
## DNS / DHCP (dnsmasq)
# create config
use a rockylinux.org domain
2022-02-19 03:15:53 +00:00
assert_script_run "printf 'domain=test.openqa.rockylinux.org\ndhcp-range=172.16.2.150,172.16.2.199\ndhcp-option=option:router,172.16.2.2\n' > /etc/dnsmasq.conf";
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# do PXE setup if this is not an update test
_pxe_setup() unless (get_var("ADVISORY_OR_TASK"));
add NFS tests (and DHCP/DNS in the support server) Summary: Set up the support server to provide DHCP/DNS functionality and an NFS server, providing a kickstart. Add a kickstart test just like the other root-user-crypted-net kickstart tests except it gets the kickstart from the support server via NFS. Also add NFS repository tests and a second support server for Server-dvd-iso flavor: this test must run on that flavor to ensure that packages are actually available. The support server just mounts the attached 'DVD' and exports it via NFS. Note we don't need to do anything clever to avoid IP conflicts between the two support servers, because os-autoinst-openvswitch ensures each worker group is on its own VLAN. As part of adding the NFS repo tests, I did a bit of cleanup, moving little things we were repeating a lot into anacondatest, and sharing the 'check if the repo was used' logic between all the tests (by making it into a test step that's loaded for all of them). I also simplified the 'was repo used' checks a bit, it seems silly to run a 'grep' command inside the VM then have os-autoinst do a grep on the output (which is effectively what we were doing before), instead we'll just use a single grep within the VM, and clean up the messy quoting/escaping a bit. Test Plan: Run all tests - at least all repository tests - and check they work (make sure the tests are actually still sane, not just that they pass). I've done runs of all the repo tests and they look good to me, but please double-check. I'm currently re-running the whole 24-20160609.n.0 test on staging with these changes. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D888
2016-06-13 15:42:30 +00:00
# open firewall ports
assert_script_run "firewall-cmd --add-service=dhcp";
assert_script_run "firewall-cmd --add-service=dns";
# start server
assert_script_run "systemctl restart dnsmasq.service";
assert_script_run "systemctl is-active dnsmasq.service";
## ISCSI
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
# start up iscsi target
Implement targetcli instead of the non-available tgtd
2022-01-30 21:30:11 +00:00
#assert_script_run "printf '<target iqn.2016-06.local.domain:support.target1>\n backing-store /dev/vdb\n incominguser test weakpassword\n</target>' > /etc/tgt/conf.d/openqa.conf";
assert_script_run "targetcli /backstores/block create dev=/dev/vdb name=vdb";
assert_script_run "targetcli /iscsi create wwn=iqn.2016-06.local.domain:support.target1";
configure iscsi acl and authetication
2022-02-19 03:16:25 +00:00
assert_script_run "targetcli /iscsi/iqn.2016-06.local.domain:support.target1/tpg1/acls create iqn.2016-06.local.domain:support.target1";
assert_script_run "targetcli /iscsi/iqn.2016-06.local.domain:support.target1/tpg1 set attribute authentication=1";
assert_script_run "targetcli /iscsi/iqn.2016-06.local.domain:support.target1/tpg1/acls/iqn.2016-06.local.domain:support.target1 set auth userid=test password=weakpassword";
Implement targetcli instead of the non-available tgtd
2022-01-30 21:30:11 +00:00
assert_script_run "targetcli /iscsi/iqn.2016-06.local.domain:support.target1/tpg1/luns create /backstores/block/vdb";
configure iscsi acl and authetication
2022-02-19 03:16:25 +00:00
assert_script_run "targetcli / saveconfig";
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
# open firewall port
Implement targetcli instead of the non-available tgtd
2022-01-30 21:30:11 +00:00
assert_script_run "firewall-cmd --add-port=3260/tcp";
assert_script_run "systemctl restart target.service";
assert_script_run "systemctl is-active target.service";
add NFS tests (and DHCP/DNS in the support server) Summary: Set up the support server to provide DHCP/DNS functionality and an NFS server, providing a kickstart. Add a kickstart test just like the other root-user-crypted-net kickstart tests except it gets the kickstart from the support server via NFS. Also add NFS repository tests and a second support server for Server-dvd-iso flavor: this test must run on that flavor to ensure that packages are actually available. The support server just mounts the attached 'DVD' and exports it via NFS. Note we don't need to do anything clever to avoid IP conflicts between the two support servers, because os-autoinst-openvswitch ensures each worker group is on its own VLAN. As part of adding the NFS repo tests, I did a bit of cleanup, moving little things we were repeating a lot into anacondatest, and sharing the 'check if the repo was used' logic between all the tests (by making it into a test step that's loaded for all of them). I also simplified the 'was repo used' checks a bit, it seems silly to run a 'grep' command inside the VM then have os-autoinst do a grep on the output (which is effectively what we were doing before), instead we'll just use a single grep within the VM, and clean up the messy quoting/escaping a bit. Test Plan: Run all tests - at least all repository tests - and check they work (make sure the tests are actually still sane, not just that they pass). I've done runs of all the repo tests and they look good to me, but please double-check. I'm currently re-running the whole 24-20160609.n.0 test on staging with these changes. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D888
2016-06-13 15:42:30 +00:00
## NFS
# create the file share
assert_script_run "mkdir -p /export";
# get the kickstart
control content of kickstart
2022-02-19 03:16:55 +00:00
assert_script_run "curl -o /export/root-user-crypted-net.ks https://git.rockylinux.org/tcooper/kickstarts/-/raw/main/root-user-crypted-net.ks";
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
# for update tests, set up the update repository and export it
Handle running update tests on Koji tasks We quite often want to run the update tests on a Koji task (not a Bodhi update) for some reason - usually to test a potential fix for an issue, or at a maintainer's request to test a change before it is merged upstream and officially sent out as an update. Up till now I've always hacked up utils.pm on the staging server by hand to do this, which is horrible. Together with a commit to fedora_openqa, this should allow us to do it in a nice, sane way via the CLI. It's mostly just tweaking the "updates" repo setup in utils.pm as you'd expect, but there's a bit of subtlety to it because of the installer tests that use %ADVISORY% as a variable substitution in the disk image name; you can't do something like `%ADVISORY or KOJITASK%`, sadly, so I had to have almost-redundant variables ADVISORY, KOJITASK and ADVISORY_OR_TASK (we could kinda just live with ADVISORY_OR_TASK except I didn't want to drop ADVISORY as it's an unnecessary change from previous behavior). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-29 09:06:16 +00:00
if (get_var("ADVISORY_OR_TASK")) {
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
assert_script_run "echo '/opt/update_repo 172.16.2.0/24(ro)' >> /etc/exports";
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
}
# for compose tests, we do all this stuff
else {
# create the repo share
assert_script_run "mkdir -p /repo";
# create a mount point for the ISO
assert_script_run "mkdir -p /mnt/iso";
# mount the ISO there
assert_script_run "mount /dev/cdrom /mnt/iso";
# copy the contents of the ISO to the repo share
Tweak NFS repo setup in _support_server to copy all files `cp -R foo/*` doesn't get all files in `foo/`, it misses hidden files. This turns out to be a problem with recent anaconda, as it expects to find a .treeinfo file here. So, let's use rsync. We could probably do this with cp too but I can't think of the right arguments right now... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-19 00:00:42 +00:00
assert_script_run "dnf -y install rsync", 180;
extend timeouts
2022-02-19 03:12:25 +00:00
assert_script_run "rsync -av /mnt/iso/ /repo", 360;
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
# put the updates image in the NFS repo (for testing this update
# image delivery method)
assert_script_run "curl -o /repo/images/updates.img https://fedorapeople.org/groups/qa/updates/updates-openqa.img";
New install_repository_nfsiso_variation This is covering the NFSISO_variation test as per: https://fedoraproject.org/wiki/QA:Testcase_install_repository_NFSISO_variation Change support_server to use support_5 disk image in templates supposed to be previously created by updated createhdds tool required for new test. Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
2019-02-04 14:46:31 +00:00
# create the iso share
assert_script_run "mkdir -p /iso";
# recreate an iso file
copy_devcdrom_as_isofile('/iso/image.iso');
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
# set up the exports
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
assert_script_run "printf '/export 172.16.2.0/24(ro)\n/repo 172.16.2.0/24(ro)\n/iso 172.16.2.0/24(ro)' > /etc/exports";
Have update installer test install the update packages (#89) In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became obvious that there's a missing feature in the new installer test for updates: the update is both used in the image build process and built into the installer environment itself, but it is not actually included in the installed package set. This can be a problem if the update has a bug that manifests *only* at install time if it is in the install transaction (which is exactly the case there), because the test will not catch this, and nor will any other test. So this commit makes `support_server` set up the update repo and serve it out via NFS when it's run in an update context, and makes the actual update install test run parallel with it and use that repository. This way the install should include the package(s) from the update. (It also of course means the test fails if an update breaks NFS or something like that, but hey, we want to know that!) A parallel commit for fedora_openqa is necessary to add the required CURRREL setting for the updates-installer flavor. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-01-25 13:41:32 +00:00
}
add NFS tests (and DHCP/DNS in the support server) Summary: Set up the support server to provide DHCP/DNS functionality and an NFS server, providing a kickstart. Add a kickstart test just like the other root-user-crypted-net kickstart tests except it gets the kickstart from the support server via NFS. Also add NFS repository tests and a second support server for Server-dvd-iso flavor: this test must run on that flavor to ensure that packages are actually available. The support server just mounts the attached 'DVD' and exports it via NFS. Note we don't need to do anything clever to avoid IP conflicts between the two support servers, because os-autoinst-openvswitch ensures each worker group is on its own VLAN. As part of adding the NFS repo tests, I did a bit of cleanup, moving little things we were repeating a lot into anacondatest, and sharing the 'check if the repo was used' logic between all the tests (by making it into a test step that's loaded for all of them). I also simplified the 'was repo used' checks a bit, it seems silly to run a 'grep' command inside the VM then have os-autoinst do a grep on the output (which is effectively what we were doing before), instead we'll just use a single grep within the VM, and clean up the messy quoting/escaping a bit. Test Plan: Run all tests - at least all repository tests - and check they work (make sure the tests are actually still sane, not just that they pass). I've done runs of all the repo tests and they look good to me, but please double-check. I'm currently re-running the whole 24-20160609.n.0 test on staging with these changes. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D888
2016-06-13 15:42:30 +00:00
# open firewall port
assert_script_run "firewall-cmd --add-service=nfs";
# start the server
assert_script_run "systemctl restart nfs-server.service";
assert_script_run "systemctl is-active nfs-server.service";
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
# report ready, wait for children
mutex_create('support_ready');
wait_for_children;
Add PXE boot test This adds a whole wodge of stuff to support_server to make it act as a PXE server, then adds a new test which boots from PXE and so should hit the PXE server. We use the NFS install repo as that can be relied on to work for a support_server install. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-08-16 00:51:57 +00:00
# upload logs in case of child failures
$self->post_fail_hook();
add an iscsi test, and a support_server test to support it Summary: this is following a SUSE model for tests where we need a server end but don't want setting up the server to constitute a real test in itself, we want it to be stable. The 'support_server' test just boots a pre-built (by createhdds) disk image, sets up networking, and runs the iSCSI server. To run the iSCSI test we need to handle networking config in anaconda (or we would need to set the support server up as a DHCP server, which may be worth considering), so this adds that. We also need to be able to specify the target device for a volume in custom partitioning, so this adds that too. Test Plan: Build the necessary support server disk image (use D883), then run the test and make sure it works. Also make sure all other tests continue to work. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D884
2016-06-09 15:43:46 +00:00
}
sub test_flags {
return { fatal => 1 };
}
1;
# vim: set sw=4 et:
Reference in New Issue Copy Permalink