action #115196
[qe-core] Prepare for ALP - Schedule Databases testsuite for ALP
100%
Description
Once #115181 is done, we can start small by testing MariaDB, SQLite, PostgreSQL and if it's possible, Redis latest available versions on ALP.
This is work we can also reuse for SLE and openSUSE Leap and TW, so for the better end of it, the tests should be small having a simpler logic than what we normally do.
Notes¶
Preferably create tickets for individual database systems.
Acceptance criteria¶
- AC1: New "Databases" test suite is created for ALP in o3 and osd
- AC2: Follow-up ticket for SLES is created
Subtasks
Related issues
History
#2
Updated by szarate 7 months ago
- Status changed from Workable to Blocked
setting to blocked by https://progress.opensuse.org/issues/115031
#7
Updated by zluo 6 months ago
https://github.com/os-autoinst/opensuse-jobgroups/pull/197/ PR for adding database tests on ALP.
#10
Updated by zluo 6 months ago
szarate wrote:
Zaoliang, Dee... What's left on this ticket? iirc enabling the transactional flavors, right?
the problem is https://github.com/os-autoinst/opensuse-jobgroups/pull/201
What I did in my PR, has been dropped by new job group.
Let's think about this change and make an update??
#11
Updated by zluo 6 months ago
my try: http://10.162.30.85/tests/5041#step/sqlite3/19
even I add standard repository from ALP, it could work because zypper exit code 5. kvm image is read-only. Non-transactional image is not provided at moment.
#13
Updated by pdostal 6 months ago
On 22. 9. 2022, at 11:13, redmine@opensuse.org wrote:
even I add standard repository from ALP, it could work because zypper exit code 5. kvm image is read-only. Non-transactional image is not provided at moment.
And you do use /sbin/transactional-update
right?
#14
Updated by zluo 6 months ago
yes, I tried this but this is not working:
http://10.162.30.85/tests/5049#step/sqlite3
Info about transactional-update:
https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-transactional-updates.html
Only packages that are part of the snapshot of the root file system can be updated. If packages contain files that are not part of the snapshot, the update could fail or break the system.
#16
Updated by zluo 6 months ago
pdostal wrote:
I don’t understand. Can you include some command line output?
I tried this:
if(check_var('DISTRI', 'alp')) {
assert_script_run('transactional-update pkg install sqlite3 expect perl');
}
else {
zypper_call('install sqlite3 expect perl');
}
Test died: command 'transactional-update pkg install sqlite3 expect perl' timed out at alp/tests/console/sqlite3.pm line 28.
#18
Updated by zluo 6 months ago
pdostal wrote:
Then maybe try this:
if (is_transactional) { trup_call('pkg install check_reboot_changes; } else { zypper_call('in firewalld'); }
no, this is not working for trup_call or trup_install:
http://10.162.30.85/tests/5054#step/sqlite3/11
Test died: Confirmation dialog not shown at alp/lib/transactional.pm line 177.
#20
Updated by szarate 6 months ago
pdostal wrote:
Then it's in my opinion a bug in
trup_call
which should be fixed.
indeed, one idea that comes to mind, is to make turp to switch to root console and then switch back to whatever was before... but it's a hack... There's https://progress.opensuse.org/issues/117028
However, for now... if if it's a transactional system, use root-console instead of serial console.
#23
Updated by dvenkatachala 6 months ago
I called the trup_call function in the root console, this seems to be working fine. Verification run after switching to the root console - sqlite3
#24
Updated by szarate 6 months ago
- Related to coordination #117028: [qe-core] Possible improvements for transactional installations added