Project

General

Profile

Actions

action #157096

closed

coordination #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.

Status:
Resolved
Priority:
High
Target version:
-
Start date:
2024-03-12
Due date:
% Done:

0%

Estimated time:

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

Actions #1

Updated by JERiveraMoya 8 months ago

  • Description updated (diff)
Actions #2

Updated by syrianidou_sofia 8 months ago

  • Assignee set to syrianidou_sofia
Actions #3

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
Actions #4

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?

Actions #5

Updated by JERiveraMoya 8 months ago

  • Description updated (diff)
Actions #6

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

Actions #7

Updated by JERiveraMoya 8 months ago

  • Priority changed from Normal to High

SLE Micro is closed to RC, setting priority to High.

Actions #8

Updated by JERiveraMoya 8 months ago

  • Status changed from Workable to In Progress
Actions #9

Updated by syrianidou_sofia 8 months ago

  • Status changed from In Progress to Workable
Actions #10

Updated by JERiveraMoya 8 months ago

  • Status changed from Workable to In Progress

I guess it is still in progress, waiting for review.

Actions #11

Updated by JERiveraMoya 8 months ago

  • Tags changed from qe-yam-mar-sprint to qe-yam-apr-sprint
Actions #12

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

Actions #13

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.

Actions #14

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=510

Yes, 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

Actions #15

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=510

Yes, 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

Actions #16

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=510

Yes, 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

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.

Actions #17

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=510

Yes, 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

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.

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.

Actions #18

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

Actions #19

Updated by syrianidou_sofia 7 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF