Install SLES 16.0 Minimal VM as guest on SLES 16.0 system #21142
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
12 times, most recently
from
50a2ca3 to
1cc7756
Compare
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
from
1cc7756 to
2f44550
Compare
|
@alice-suse @guoxuguang @Julie-CAO @RoyCai7 @nanzhg @tbaev Please have a look. |
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
3 times, most recently
from
c654181 to
14e7700
Compare
| # 08) test networking | ||
| # 09) do registration | ||
| # 10) refresh repositories | ||
| # 11) leave a marker |
There was a problem hiding this comment.
Just to confirm combustion works well for sle16 vm?
This script does quite some work. If it returns non-zero on one of the lines, will it be easily observed in openqa job? And how?
Would you please explain a little bit why the name is chosen and its target vms to use it?
There was a problem hiding this comment.
It works well for all VMs. Script debugging already turned on.
There was a problem hiding this comment.
Yes, noticed. I mean if some product bug or infra problem happens, eg suseconnect fails, how do we debug based on current solution? Based on my experience in sle micro combustion, we need to rely on journal log for details, but I do not remember if it will always cause second boot failure if one line returns non-zero in the middle.
There was a problem hiding this comment.
Open guest console, login to emergency and cat /run/initramfs/rdsosreport.txt can also help I think.
There was a problem hiding this comment.
Yes, that's for critical failures at running combustion script, eg script timeout. So it is easy to observe in openqa job for such case, because it will be red.
Maybe let me try to rephrase. My point was that, for those uncritical failures when running combustion script, but is critical for automation, eg the line of registering the system, when such line fails, is it easy to observe in openqa job? Do we need to do special handling for such situations, eg additional check in journal after second boot up(combustion finishes and go here, and I guess openqa job green until now?)? May need to emulate and see how it turns out.
There was a problem hiding this comment.
I just use /run/initramfs/rdsosreport.txt to see any failed commands in combustion script. I did this many times already. When guest fails to boot up, it can be easily seen from openQA job.
There was a problem hiding this comment.
Good! Has this log been uploaded for failure job? BTW, would you please add a failure job for reference? Just to ensure that the automation test can rely on uploaded logs for debug.
Also, maybe I am repeating myself, but I do not see this answered yet... You gave how to handle when guest fails to boot up. What about the case that guest does not fail to boot, but it fails at some combustion script steps, eg registration line by network problem? Can current code detect such combustion failure by specific checking after vm installation? Maybe it seems corner case for now, but I believe it will have chance to happen when frequent daily builds need to be tested for sle16 later.
There was a problem hiding this comment.
It is very easy to debug. Connect to guest console, enter into maintenance and list interested files. Every step can be seen. You can see the failure here. This is just similar to SL Micro 6.x disk image which also uses ignition and combustion.
| $self->prepare_bootloader; | ||
| $self->prepare_services; | ||
| $self->prepare_reboot; | ||
| $self->restore_ground; |
There was a problem hiding this comment.
@Julie-CAO would you please give it a review if these steps have any redundancy with host installation setup from the regard of OS preparation?
There was a problem hiding this comment.
I do not think there is any duplicate.
|
What's the difference about these two jobs? I do not quite get it... |
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
from
14e7700 to
74d9c78
Compare
It is just about how combustion config is passed in, either a qcow disk or just virt-install parameters. Either is OK. |
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
2 times, most recently
from
5cb58f1 to
9ad096c
Compare
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
2 times, most recently
from
f83b9a8 to
77413f5
Compare
1.New module prepare_non_transactional_server.pm to perform all necessary operations on non-transactional system before doing actual work like virtual machine installation. 2.New subroutine is_reboot_needed in lib/utils.pm to determine whether system reboot is needed after changes being made. It uses setting NEEDS_REBOOTING or returned code of zypper needs-rebooting to judge whether reboot is needed. 3.New guest profile sles_16_64_kvm_hvm_x86_64_qcow_ignition+combustion.xml to represent SLES 16.0 Minimal VM for x86_64. 4.New combustion script combustion_script_all_round to perform all necessary tasks, including adding user, setting passwords, adding ssh public keys, starting services, doing registration and etc, in order to have a fully up and running system. 5.Introduce new test suite level setting UNIFIED_GUEST_BUILDS for unified guest installation because SLES 16.0 Minimal VM may have different build than agama installer. 6.Update virtualization server patterns for SLES 16.0. 7.Use ##Authorized-Keys## and ##FQDN## in combustion_script_all_round. 8.New subroutine install_extra_packages in lib/utils.pm to wrap up already existing similar functionality in multiple modules. 9.Exclude 127.0.0.0/8 subnet from being scanned in logs collecting scripts, including: data/virt_autotest/virt_logs_collector.sh data/virt_autotest/fetch_logs_from_guest.sh
waynechen55
force-pushed
the
wayne/install_sles16_iso_as_guest
branch
from
77413f5 to
590d221
Compare
New module
tests/virt_autotest/prepare_non_transactional_server.pmto perform all necessary or potential operations on non-transactional system before doing actual work like virtual machine installation. These operations may involve extra packages installation, product and extension registration, grub modification and many others.New subroutine
is_reboot_neededinlib/utils.pmto determine whether system reboot is needed after changes being made. It uses settingNEEDS_REBOOTINGor returned code ofzypper needs-rebootingto judge whether reboot is really needed.New subroutine
install_extra_packagesinlib/utils.pmto wrap up already existing similar functionality in multiple modules, for example,tests/virt_autotest/prepare_non_transactional_server.pmandtests/virt_autotest/prepare_transactional_server.pm.New guest profile
data/virt_autotest/guest_params_xml_files/sles_16_64_kvm_hvm_x86_64_qcow_ignition+combustion.xmlto represent SLES 16.0 Minimal VM for x86_64.New combustion script
data/virt_autotest/guest_unattended_installation_files/combustion_script_all_roundto perform all necessary tasks, including adding user, setting passwords, adding ssh public keys, starting services, doing registration and etc, in order to have a fully up and running system. This is useful especially when ignition does not work very well.Use
##Authorized-Keys##and##FQDN##indata/virt_autotest/guest_unattended_installation_files/combustion_script_all_round.Introduce new test suite level setting
UNIFIED_GUEST_BUILDSfor unified guest installation because SLES 16.0 Minimal VM may have different build than agama installer.Update virtualization server patterns for SLES 16.0.
Exclude
127.0.0.0/8subnet from being scanned indata/virt_autotest/virt_logs_collector.shanddata/virt_autotest/fetch_logs_from_guest.sh.Verification Runs: