action #114481
closed[SLES 15 SP5] Ensure that Packagehub KDE scenario is tested during migration tests
0%
Description
Hello team,
the PackageHub for 15 SP4 was bit broken on release. And we've got escalation from Matthias Eckermann regarding this.
SUSE has been a big sponsor of the KDE PackageHub usecase and we'd like to ensure that any issues are catched early.
If we can extend any existing suite for 15 SP5 that utilizes Package Hub that would be great.
Updated by lkocman almost 2 years ago
An idea could be to use one of Leap tests suites, and just ensure that it's executed on top of SLES + Package Hub.
Updated by maritawerner almost 2 years ago
- Status changed from New to Rejected
Lubos, we only test that package Hub works in general (=just install the module), we do not make sure that any package in package hub works properly. That is excluded from our test plans. And KDE is not available on SLES as well. Not sure what Matthias Eckerman's idea is here. And let me add that package hub itself comes always super late into the game, it is not aviable for testing most of the time.
Updated by lkocman almost 2 years ago
PackageHub after (and perhaps including) Leap 15.5 is planned to be automated https://progress.opensuse.org/issues/114478 #114478
Having some sanity check (e.g. testing KDE availability) that all worked, would really ensure that we can provide "quality" service to SUSE's customers.
KDE + some basic test suite from leap is just a nice example how to test "availability of larger block of packages". The nice thing about KDE is that QT part is from SLES including stuff like kwallet, and quote some part also comes from LEAP. So technically we test that both SLES unshipped + Leap specific packages are avialable to customers.
Any other secenario that would in general ensure that there is "majority of content" would be also acceptable. Also basic KDE test suite is already availble.
Updated by lkocman almost 2 years ago
Another way to test it would be e.g. to compare 15 SP5 Packagehub content with SP4 PackageHub and see if we do not regress on package count and software versions.
We do not plan to update packagehub for sp5+ therefore we could just test if the SP5 content + few updates are available to SP6 and SP7 users. That I think could work as well.
Updated by okurz almost 2 years ago
Some notes after jstehlik discussed this topic with me as well:
- There is no significant expected impact in hardware ressources for both o3 and osd to support this scenario in tests
- Any such scenario would very likely be just the same as already existing Leap+KDE openQA tests with the notable difference of just using package hub as the source for the packages to install from.
- Maybe what could be done is to just copy a pre-installed SLE+PackageHub installation from OSD into fixed assets and then conduct an upgrade/migration like we already do in various other openSUSE/SLE tests
Updated by jstehlik almost 2 years ago
The goal is to have packagehub sufficiently tested while keeping the agreed scope definition of not testing packagehub content.
This ticket will stay rejected, but I advised Lubos to open a new one with another proposal of improving the packagehub test which already exists in SLES with check of number of packages which shall in near future stay relatively stable.