os-autoinst-distri-opensuse
os-autoinst-distri-opensuse copied to clipboard
os-autoinst
[wip][virtualization][alp] Extend guest installation for imported disks and virtual network
As title.
To be udpated.
- Related ticket: https://progress.opensuse.org/issues/xyz
- Needles: https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/xyz
- Verification run: openqa.mypersonalinstance.de/tests/xyz#step/module/x
Great PR! Please pay attention to the following items before merging:
Files matching lib/**.pm:
- [ ] Consider adding or extending unit tests in t/
This is an automatically generated QA checklist based on modified files
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@Julie-CAO @guoxuguang @waynechen55 @nanzhg @tbaev @RoyCai7 @martinsmarcelo Welcome review!
You need also do verification run for oracle linux test suite which installs multiple guests. Additionally do verification run with multiple SLES guests on SLES host. And I also think you should do verification on ALP with multiple guests as well.
You need also do verification run for oracle linux test suite which installs multiple guests. Additionally do verification run with multiple SLES guests on SLES host.
oracle guests: wip, https://openqa.suse.de/tests/10041941#live
There seems no any job on osd with multiple sles guest on sles host. Xen host tests have 1 guest too. Besides, actually the PR does not change logic on installing PARALLEL guests with additional different handling on different kinds of hosts. Given that multiple guests scenario has been verified on alp, oracle guest on sles guest, i think it should be fine without validation for multiple sles guest on sles host.
And I also think you should do verification on ALP with multiple guests as well.
They are given in validation tests already. On ALP:
PASS: 2 imported disk vm with vnet(alp, sle15sp3) , http://10.67.129.185/tests/391 PASS: 1 sle15sp4 vm with installation url with vnet, http://10.67.129.185/tests/393# PASS: 3 vms(2 with imported disk(alp, sle15sp3), 1 with installation url(sle15sp4)), http://10.67.129.185/tests/397 FAIL(fail on purpose to verify post_fail_hook): 1 alp vm, http://10.67.129.185/tests/380 FAIL(fail on purpose to verify post_fail_hook): 2 vm(1 alp, 1 sles): http://10.67.129.185/tests/399
Not sure what is the final form of this kvm container. Will it become a systemd managed service and provide service directly to client on host (no need to enter into it) ? If this is possible, how would you handle the change ?
Not sure what is the final form of this kvm container. Will it become a systemd managed service and provide service directly to client on host (no need to enter into it) ? If this is possible, how would you handle the change ?
Good question! Even if it becomes a service(very likely via the libvirtd.service file I shared you in last PR), there won't be any magic actually. The kvm container start/stop/restart will be managed by new libvirtd.service, but nothing else. The virtualization sack will still be given in kvm container. How it can be used will be the same as it is now -- enter the container, or podman exec -ti libvirtd xx, or use the wrapped script virsh.sh (given in the kvm workload repo). Just as why we choose entering container for automation test initially, we will choose the same choice after it is managed by new libvirtd service.
You need also do verification run for oracle linux test suite which installs multiple guests. Additionally do verification run with multiple SLES guests on SLES host.
oracle guests: wip, https://openqa.suse.de/tests/10041941#live
In this job, 2 oracle guests passed, and 1 oracle kernel panic. See failure in https://openqa.suse.de/tests/10041941#step/unified_guest_installation/3296.
I also checked OSD official job group with the same build 50.1:
- https://openqa.suse.de/tests/10039717#step/unified_guest_installation/3188 failed with same error (8:44 hours),
- but the latest rerun passed in https://openqa.suse.de/tests/10042000 (2:35 hours)
@waynechen55 I am afraid this will need you to further debug the kernel panic issue. It should have nothing to do with this PR. Besides, the failure job will take ~9 hours. Better to let fail stop sooner? Created https://progress.opensuse.org/issues/121069 to track it.
Latest verification run after code rework for https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15939#discussion_r1033089868 and https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15939#discussion_r1033077968 : http://10.67.129.185/tests/400# // 3 vms, with imported disk and installation url mixed, pass well; should be enough for the changes
Hello all, this PR is open for almost a week for review. Thanks to who have reviewed. If anyone else has comment, feel free to give. If no before EOB tomorrow, I plan to merge it. Thanks!
Rebased to the latest merged PRs of today (PR #15995 and PR #15985), new verification run passes: http://10.67.129.185/tests/401#.