action #157096
closedcoordination #157093: [epic] Extend SL(E) Micro test coverage
Add rollback after SLEM 5.5 migration to SLEM 6.0
Added by JERiveraMoya 8 months ago. Updated 7 months ago.
0%
Description
Motivation¶
See epic and Slack conversation (for participants to discuss further info).
Acceptance criteria¶
AC1: All migration SLEM 5.5 to SLEM 6.0 perform a rollback.
Additional information¶
Existing migrations: https://openqa.suse.de/group_overview/510
In bsc#1220679 was mentioned the need of this regression test case and that could be performed with
SUSEConnect --rollback.
Rollback doc (but not specific to migration): https://documentation.suse.com/smart/systems-management/html/SLE-Micro-admin/index.html#tr-up-rollback
Updated by josegomezr 8 months ago
From my notes (I'm not an expert in transactional-systems).
Grab a test with the default SLEM5.5 image: sle-micro-5.5-Default-Updates-x86_64-slem_image_default@64bit
# 1. activate the system
$ transactional-update register -r %regcode%
$ reboot
# dup
$ transactional-update dup
$ reboot
# migrate
$ transactional-update migration
$ reboot
# check that we're on the new version
$ zypper products -i
Updated by JERiveraMoya 8 months ago · Edited
josegomezr wrote in #note-3:
From my notes (I'm not an expert in transactional-systems).
Grab a test with the default SLEM5.5 image: sle-micro-5.5-Default-Updates-x86_64-slem_image_default@64bit
# 1. activate the system $ transactional-update register -r %regcode% $ reboot # dup $ transactional-update dup $ reboot # migrate $ transactional-update migration $ reboot # check that we're on the new version $ zypper products -i
Thanks @josegomezr, actually the migration is already automated, but the rollback part I guess is that only that command described in the ticket, right?
Updated by josegomezr 8 months ago
No, it should be a normal system rollback, adding to my notes before (I didn't got to the stage of running a rollback before cuz I hit some other roadblocks).
[...]
$ zypper products -i
$ transactional-updates rollback <snapshot-number-of-the-previous-version>
$ reboot
# check we're on 5.5 again
$ zypper products -i
with this I think it should be possible to do 5.5 -> 6.0 -> 5.5
Updated by JERiveraMoya 8 months ago
- Priority changed from Normal to High
SLE Micro is closed to RC, setting priority to High.
Updated by JERiveraMoya 8 months ago
- Status changed from Workable to In Progress
Updated by syrianidou_sofia 8 months ago
- Status changed from In Progress to Workable
Updated by JERiveraMoya 8 months ago
- Status changed from Workable to In Progress
I guess it is still in progress, waiting for review.
Updated by JERiveraMoya 8 months ago
- Tags changed from qe-yam-mar-sprint to qe-yam-apr-sprint
Updated by JERiveraMoya 8 months ago · Edited
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510
Updated by syrianidou_sofia 8 months ago
JERiveraMoya wrote in #note-12:
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510
Yes, I remember I had excluded a few modules from the schedule and rollback worked.
Updated by JERiveraMoya 8 months ago
syrianidou_sofia wrote in #note-13:
JERiveraMoya wrote in #note-12:
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510Yes, I remember I had excluded a few modules from the schedule and rollback worked.
today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510
Updated by syrianidou_sofia 8 months ago
JERiveraMoya wrote in #note-14:
syrianidou_sofia wrote in #note-13:
JERiveraMoya wrote in #note-12:
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510Yes, I remember I had excluded a few modules from the schedule and rollback worked.
today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510
The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testing
Updated by JERiveraMoya 7 months ago · Edited
syrianidou_sofia wrote in #note-15:
JERiveraMoya wrote in #note-14:
syrianidou_sofia wrote in #note-13:
JERiveraMoya wrote in #note-12:
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510Yes, I remember I had excluded a few modules from the schedule and rollback worked.
today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testing
Does it make any difference to use process_reboot(trigger => 1) in the same way that suseconnect_scc does? Looks like the problem is even before the rollback, so a normal reboot is needed.
Updated by syrianidou_sofia 7 months ago
JERiveraMoya wrote in #note-16:
syrianidou_sofia wrote in #note-15:
JERiveraMoya wrote in #note-14:
syrianidou_sofia wrote in #note-13:
JERiveraMoya wrote in #note-12:
if you skip the journal check, does the rollback work for aarch64 and x86_64?
https://openqa.suse.de/tests/overview?distri=sle-micro&version=6.0&build=5.12&groupid=510Yes, I remember I had excluded a few modules from the schedule and rollback worked.
today is failing only for 2 architectures:
https://openqa.suse.de/tests/overview?result=failed&result=incomplete&result=timeout_exceeded&distri=sle-micro&version=6.0&build=7.3&groupid=510The problem seems to be that grub2 is not displayed when the system reboots. Even though we can see it here: https://openqa.suse.de/tests/13972705#step/suseconnect_scc/27
I tried here with QEMURAM=2048 and it failed again. I thought it's a timeout issue, thus I paused and connected via vnc. Grub was perfectly visible, but the openqa screen was not updated accordingly. So, the issue seems quite strange, most likely infra problem. I will ask in #eng-testingDoes it make any difference to use
process_reboot(trigger => 1)in the same way thatsuseconnect_sccdoes? Looks like the problem is even before the rollback, so a normal reboot is needed.
Indeed, if I remove all modules between migration and rollback, the reboot works. I tried the suggestion from Marrius to reset_consoles but that doesn't help. I will try to replace the reboot and see if it helps.
Updated by syrianidou_sofia 7 months ago
It works indeed, even for s390x. I have made a PR here and waiting for second VRs to pass
Updated by syrianidou_sofia 7 months ago
- Status changed from In Progress to Resolved