Temp: To support IPXE TW install on vh001and Enable virtual Network Tests

[varunkojha]

• Description

To support IPXE Tumbleweed install on vh001 to continue working on Feature enabling for #94801 and fixing installation issues to run network tests until O3 rebel migration is complete.

Addressing / work-around for blocker POO #132647

This PR will be a rework and to extend the PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17739 Enable Tumbleweed feature tests and automation changes after guest installation

The following tests are enabled when this PR is ready and the Automation changes are done locally and kept for future to add it to O3. Tumbleweed openqa test (to be moved into official group once stable): https://openqa.opensuse.org/group_overview/38

• Related ticket: https://progress.opensuse.org/issues/137606 Extending and re-work for https://progress.opensuse.org/issues/94801
• Verification runs:

KVM Guest installation tests pass: http://10.137.0.177/tests/168# virtual_network_test pass: http://10.137.0.177/tests/170# libvirt_virtual_network_init, libvirt_nated_virtual_network & libvirt_host_bridge_virtual_network all pass: http://10.137.0.177/tests/176#

XEN Guest installation tests pass: http://10.137.0.177/tests/172# libvirt_virtual_network_init pass: http://10.137.0.177/tests/175# libvirt_host_bridge_virtual_network test pass: http://10.137.0.177/tests/180#
libvirt_nated_virtual_network test pass: http://10.137.0.177/tests/182#

[varunkojha]

Test run: couldn't start http://10.137.0.177/tests/129# http://vojha-openqa.qe.suse.de/tests/133

Run started failed at unified_guest_installation: http://10.137.0.177/tests/134# http://10.137.0.177/tests/135# http://10.137.0.177/tests/136#live

[github-actions[bot]]

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.

[varunkojha]

@Julie-CAO had a successful, guest installation http://10.137.0.177/tests/164#

[varunkojha]

Successful run after guest installation for virtual network test in KVM on vh001 passed: http://10.137.0.177/tests/170#

[varunkojha]

Actions Completed:

1. Fixed errors for guest installation using ipxe
2. Add changes from PR Enable Tumbleweed feature tests and automation changes after guest installation #17739
3. Check impact and monitor issues on the latest snapshots on the VH001 machine
4. Use repo http://openqa.qa2.suse.asia/assets/repo/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20231001/ and later ones when available, Snapshot20231006 & Snapshot20231020
5. Enable Virtual Network tests at least

Please note packages like nmap, sshpass, and support utils are not present in the snapshot used. http://openqa.qa2.suse.asia/assets/repo/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20231020/

Below virtual_network_test enabled for both XEN and KVM and this PR is to keep track for keeping the automation changes locally, same or similar implementation would be done when O3 is back:

• virt_autotest/libvirt_virtual_network_init
• virt_autotest/libvirt_nated_virtual_network
• virt_autotest/libvirt_host_bridge_virtual_network

@alice-suse @guoxuguang @Julie-CAO @RoyCai7 @nanzhg @tonyyuan1 @waynechen55 Please have a look. Thanks!! :)

[Julie-CAO]

Since tt is a temp PR, so I asume that

• Your final PR will only include the changes in virtual network tests.

• Those changes which are based on your local test envionment, such as the installation medium location in guest parameter files, are not applicable on O3. Therefor, this type changes will not be included in this PR finally, you just keep them in your personal openqa server.

• The changes about nmap will not be included in the PR finally either. You find that nmap package is not available in TW repo in the snapshot in Beijing Mirror server. From which repo did it come in previous tests on O3? Do you have some idea on whether it is available via other repos, or can it be installed in other means? If not, as it is widely used in tests, to get guest IP, to check if guest is online and to collect logs, it is risky that just skip it in the tests. you'd better have some idea about finding an alternative tool or finding another way to get all these things done.

[varunkojha]

Since tt is a temp PR, so I asume that

• Your final PR will only include the changes in virtual network tests.
• Those changes which are based on your local test envionment, such as the installation medium location in guest parameter files, are not applicable on O3. Therefor, this type changes will not be included in this PR finally, you just keep them in your personal openqa server.
• The changes about nmap will not be included in the PR finally either. You find that nmap package is not available in TW repo in the snapshot in Beijing Mirror server. From which repo did it come in previous tests on O3? Do you have some idea on whether it is available via other repos, or can it be installed in other means? If not, as it is widely used in tests, to get guest IP, to check if guest is online and to collect logs, it is risky that just skip it in the tests. you'd better have some idea about finding an alternative tool or finding another way to get all these things done.

Yes Julie I agree with all 3 points of yours, thanks for putting and highlighting it here

For the alternate part for nmap let's wait till our O3 and I have the below solution to propose, which I think should not be required.

nc -z -w 2 example.com 22 Expected Output: Connection to example.com 22 port [tcp/ssh] succeeded!

[alice-suse]

@varunkojha Glad to see the progress on enabling virtual network test. After looking through the PR, maybe some general suggestions will be good to be given first.

1. this repo, https://github.com/os-autoinst/os-autoinst-distri-opensuse, is for official code. When there are known temporary code which won't be kept in official code, suggest to break the code into commits, and only submit PR for those commits targeting for official code.
2. For the code to make test work in BJ, given that O3 and BJ have known differences, and some part of code that works on O3 won't work for BJ, but we have the need to run test in BJ for debug/automation purposes, so you can make this part of code persistent in official code via PR, but better to make it if xx;O3, else BJ. Needle differentiation or ip range check can help with this purpose. You can refer to boot_from_pxe for some examples with needle differentiation.
3. for code changes in virtual network test modules, you have actually skipped quite some checks with if !is_tumbleweed. Please think about if it will be the case in official test code. One important rule is that we shall NOT cutoff test coverage WITHOUT GOOD REASONS (eg a common good reason is that it is not supported in the product ).

[waynechen55]

1. Could you help explain your changes with regard to is_tumbleweed ? Why you need to add is_tumbleweed ?
2. Do you use NetworkManager or wicked on tumbleweed ?

[varunkojha]

• Could you help explain your changes with regard to is_tumbleweed ? Why you need to add is_tumbleweed ?
• Do you use NetworkManager or wicked on tumbleweed ?

Yes Wayne NM is used for TW. Leon might have mentioned this before "Regarding virtual network part, enabled Network Manager by default both on ALP and TW far now. Meanwhile, still use with wicked by default in SLE. So, we need to set up host bridge network via nmcli both alp and TW together without SLE". That's why I added is_tumbleweed

Changes with is_tumbleweed: The addition of if (!is_tumbleweed) is a condition in the script. This condition ensures that the subsequent script_retry block, involving the use of nmap, is executed only if the operating system is not Tumbleweed. In summary, the condition if (!is_tumbleweed) is added to adapt the script's behavior based on the specific characteristics or requirements of Tumbleweed.

[waynechen55]

• Could you help explain your changes with regard to is_tumbleweed ? Why you need to add is_tumbleweed ?
• Do you use NetworkManager or wicked on tumbleweed ?

Yes Wayne NM is used for TW. Leon might have mentioned this before "Regarding virtual network part, enabled Network Manager by default both on ALP and TW far now. Meanwhile, still use with wicked by default in SLE. So, we need to set up host bridge network via nmcli both alp and TW together without SLE". That's why I added is_tumbleweed

Changes with is_tumbleweed: The addition of if (!is_tumbleweed) is a condition in the script. This condition ensures that the subsequent script_retry block, involving the use of nmap, is executed only if the operating system is not Tumbleweed. In summary, the condition if (!is_tumbleweed) is added to adapt the script's behavior based on the specific characteristics or requirements of Tumbleweed.

Why do you need to skip get_guest_ipaddr and collect_guest_installation_logs_via_ssh ?

[varunkojha]

Why do you need to skip get_guest_ipaddr and collect_guest_installation_logs_via_ssh ?

get_guest_ipaddr this is done by nmap and it is not available in the snapshot and the dir $common_log_folder/nmap_subnets_scan_results/nmap_scan_$single_subnet is not created in this case, so I skipped to make other things run and verify which I need for virtual network tests. Also, Dynamic IP Address Change After Reboot: In Tumbleweed, the IP address is checked multiple times even if an IP has been detected, indicating a dynamic allocation that might change during the guest's lifecycle.

For collect_guest_installation_logs_via_ssh: similar things it uses nmap and SSH Port Open Check: The method attempts to collect guest installation logs via SSH. Before doing so, it checks whether the SSH port is open on the guest's IP address and nmap is needed for that. In Tumbleweed, there may be considerations related to the guest's behavior, SSH availability, or other factors so I decided to skip the SSH-based log collection.

Please Note: this might not be the case when O3 is back. Rework will be needed.

[varunkojha]

@varunkojha Glad to see the progress on enabling virtual network test. After looking through the PR, maybe some general suggestions will be good to be given first.

1. this repo, https://github.com/os-autoinst/os-autoinst-distri-opensuse, is for official code. When there are known temporary code which won't be kept in official code, suggest to break the code into commits, and only submit PR for those commits targeting for official code.
2. For the code to make test work in BJ, given that O3 and BJ have known differences, and some part of code that works on O3 won't work for BJ, but we have the need to run test in BJ for debug/automation purposes, so you can make this part of code persistent in official code via PR, but better to make it if xx;O3, else BJ. Needle differentiation or ip range check can help with this purpose. You can refer to boot_from_pxe for some examples with needle differentiation.
3. for code changes in virtual network test modules, you have actually skipped quite some checks with if !is_tumbleweed. Please think about if it will be the case in official test code. One important rule is that we shall NOT cutoff test coverage WITHOUT GOOD REASONS (eg a common good reason is that it is not supported in the product ).

I agree Alice,

Thanks @alice-suse a lot for your thorough review and valuable suggestions. Your insights are helpful, and I'm committed to refining the virtual network test based on your feedback.

Temporary Code in Official Repo: I appreciate the suggestion regarding known temporary code. I'll make sure to break such code into separate commits, submitting PRs exclusively for official code-related changes.

Handling Differences Between O3 and BJ: Your point about O3 and BJ differences is well-taken. I'll modify the code to accommodate these variations, making it persistent in the official code. Conditional checks and examples from boot_from_pxe I will check in achieving this more effectively.

Tumbleweed Checks in Virtual Network Test Modules: Thank you for highlighting the skipped checks. I'll revisit and reconsider the checks with if !is_tumbleweed. Ensuring comprehensive test coverage is a priority, and we'll make adjustments as needed, adhering to the rule of not cutting off test coverage without valid reasons. And I think I already covered the majority part and only skipped guest IP availbility and nmap part.

I'm dedicated to delivering high-quality and maintainable code, and your feedback is instrumental in achieving that. If you have any further specifics or additional areas to focus on, please let me know. I will take Leon, Julie and Wayne help if needed to acheive this as they have more experience on the same. Looking forward to continued collaboration!