action #108227
closed
coordination #108224: Implement YaST modules with libyui REST API
Migrate to libyui REST API yast2 scc
Added by JERiveraMoya about 2 years ago.
Updated over 1 year ago.
Description
Motivation¶
We perform registration of an unregistered system in test suite select_modules_and_patterns+registration with test module
suseconnect_scc: https://openqa.suse.de/tests/8291092#step/suseconnect_scc/26
On the other hand we have another test suite which boot a registered system with basesystem,server and desktop and unregister it and install basesystem,server,desktop,development modules with test module installation/addon_products_via_SCC_yast2 as follows:
https://openqa.suse.de/tests/8292986#step/addon_products_via_SCC_yast2/35
https://openqa.suse.de/tests/8291739#step/addon_products_via_SCC_yast2/7
which has a wrong name due it has dependency in the past from some sdk test suite.
As we clean the registration in the second case, with the first test case should be enough to test this functionality and we use YaST tools instead of userspace tools.
We should consider to migrate to libyui REST API for this YaST module, which is also one (if not the most) used by customers.
Acceptance criteria¶
AC1: Migrate YaST module 'yast2 scc' to libyui REST API and schedule in test suite select_modules_and_patterns+registration
AC2: Remove test suite sles+sdk+proxy_SCC_via_YaST
Suggestion¶
- Probably we don't have a test yet that use libyui for installation and after first boot in single test suite but it should work, still please remember that we do some adjustments when we create image for libyui (ports, etc.) which in the installed system might be needed as well.
- Avoid to rewrite the existing old code and focus on new approach we use for installation. For opening modules in the install system we used
YaST::Module. Be aware the code for the installed system is not so organized.
- Last part of the test we will need to use some needling as package selection does not work with libyui REST API. Create a new test module to avoid mixing non-libyui REST API with shortcuts/needles approach.
- Notice that after package selection which cannot be done with libyui, a class YPackageSelector will appear there not allowing instrospection, we will get to "Installation summary" which we can automate with libyui and check the summary using Mojo lib to parse hmtl and perhaps some additional regex, like we did recently for partitioning proposal.
Files
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
- Tags deleted (
qe-yast-refinement)
- Status changed from New to Workable
- Status changed from Workable to In Progress
- Status changed from In Progress to Workable
Unassigning you to not confuse newcomers about the workable column.
- Status changed from Workable to In Progress
After installation of select_modules_and_patterns+registration, we can not found any SUSEConnect configuration file, so we have to do SUSEConnect configuration before we start registration test.
susetest:~ # ll /etc/SUSE*
-rw-r--r-- 1 root root 17 May 8 04:29 /etc/SUSE-brand
So we have to some preparation work(such as echo "http:proxy.xxxx > /etc/SUSEConnect") before yast scc libyui check.
No any pattern can cover libyui-rest-api16 which needed for libyui test.
for i in "32bit apparmor base common-criteria devel_basis devel_kernel devel_yast dhcp_dns_server directory_server documentation enhanced_base file_server fips fonts gateway_server gnome_basic kvm_server kvm_tools lamp_server mail_server ofed oracle_server print_server sap_server sw_management x11 x11_yast xen_server xen_tools yast2_basis yast2_desktop yast2_server"; do zypper info -t pattern $i >1;grep -risn libyui- ./1 ; done
256: i | libyui-ncurses-devel | package | Recommended
257: i | libyui-qt-devel | package | Recommended
698: i | libyui-ncurses-pkg16 | package | Recommended
699: i | libyui-ncurses16 | package | Recommended
890: i | libyui-qt16 | package | Required
899: i | libyui-qt-pkg16 | package | Recommended
900: i | libyui-qt16 | package | Recommended
933: i | libyui-qt-pkg16 | package | Recommended
992: i | libyui-ncurses-pkg16 | package | Recommended
993: i | libyui-ncurses16 | package | Recommended
1018: i | libyui-ncurses-pkg16 | package | Required
susetest:~ # zypper info liyui-rest
Refreshing service 'Basesystem_Module_15_SP4_x86_64'.
Refreshing service 'Desktop_Applications_Module_15_SP4_x86_64'.
Refreshing service 'Development_Tools_Module_15_SP4_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP4_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP4_x86_64'.
Loading repository data...
Reading installed packages...
Information for package libyui-rest-api16:¶
Repository : SLE-Module-DevTools15-SP4-Pool
Name : libyui-rest-api16
Version : 4.3.3-150400.1.4
Arch : x86_64
Vendor : SUSE LLC https://www.suse.com/
Support Level : Level 3
Installed Size : 252.2 KiB
Installed : No
Status : not installed
Source package : libyui-rest-api-4.3.3-150400.1.4.src
Upstream URL : http://github.com/libyui
Summary : Libyui - REST API plugin, the shared part
Description :
This package provides a libyui REST API plugin.
It allows inspecting and controlling the UI remotely via
an HTTP REST API, it is designed for automated tests.
So we can not install libyui-rest-api16 using current select pattern module.
For this scenario, if we SKIP install libyui-rest-api16 on running system, we have to install by search package during installation, but currently seems we have no test code can cover this requirement. see pic
- Related to action #112574: Migrate qam-yast_self_update+15 (only the part before adding add-ons) to libyui REST in YaST MU added
- Status changed from In Progress to Resolved
- Related to action #110776: Migrate sles+sdk+proxy_SCC_via_YaST from PowerKVM to PowerVM added
Also available in: Atom
PDF
