Project

General

Profile

Actions

action #110437

closed

Verify if we can shutdown from GUI in backend s390x

Added by JERiveraMoya almost 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-04-29
Due date:
% Done:

0%

Estimated time:

Description

Motivation

A workaround was introduced a time ago https://openqa.suse.de/tests/8635046#step/shutdown/8
where we avoid shutdown of the system from graphical UI:

if (is_backend_s390x) {
   record_soft_failure('poo#58127 - Temporary workaround, because shutdown module is marked as failed on s390x backend when shutting down from GUI.');
   select_console 'root-console';
   enter_cmd "$action";
            }

We only shutdown the system in one test suite in YaST group for Product Validation:
https://openqa.suse.de/tests/overview?arch=&flavor=&machine=s390x-zVM-vswitch-l2%2Cs390x-zVM-vswitch-l3&test=&modules=&module_re=&distri=sle&version=15-SP4&build=137.1&groupid=129#
select_modules_and_patterns+registration

Acceptance criteria

AC1: run 10+ verification to check that we can shutdown from GUI
AC2: if succeed, remove workaround, if not file a bug and communicate desktop squad/slack channel.

Actions #1

Updated by JERiveraMoya almost 2 years ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable
Actions #2

Updated by rainerkoenig almost 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to rainerkoenig
Actions #3

Updated by rainerkoenig almost 2 years ago

Result of the verification runs: FAIL

Findings

Based on this VR (S390-zVM):

Screenshots look quite the same like on S390-KVM here, but shutdown test gets canceled

Looking at autoinst-log.txt (failed test):

[2022-05-13T05:03:57.867209+02:00] [debug] assert_shutdown_with_soft_timeout(): soft_timeout=60
[2022-05-13T05:03:57.867382+02:00] [debug] tests/shutdown/shutdown.pm:16 called power_action_utils::power_action -> lib/power_action_utils.pm:324 called power_action_utils::assert_shutdown_with_soft_timeout -> lib/power_action_utils.pm:413 called testapi::check_shutdown
[2022-05-13T05:03:57.867513+02:00] [debug] <<< testapi::check_shutdown(timeout=60)
[2022-05-13T05:03:57.868149+02:00] [debug] Backend does not implement is_shutdown - just sleeping
[2022-05-13T05:04:01.755365+02:00] [debug] considering VNC stalled, no update for 4.00 seconds
[2022-05-13T05:04:01.759817+02:00] [info] ::: backend::baseclass::die_handler: Backend process died, backend errors are reported below in the following lines:
  unexpected end of data at /usr/lib/os-autoinst/consoles/VNC.pm line 179.
[2022-05-13T05:04:01.760201+02:00] [debug] Passing remaining frames to the video encoder
[2022-05-13T05:04:01.790305+02:00] [debug] Waiting for video encoder to finalize the video
[2022-05-13T05:04:01.790448+02:00] [debug] The built-in video encoder (pid 1516) terminated
[2022-05-13T05:04:01.790680+02:00] [debug] sending magic and exit
[2022-05-13T05:04:01.791367+02:00] [debug] received magic close
Use of uninitialized value $fname in concatenation (.) or string at /usr/lib/os-autoinst/log.pm line 57.
    log::fctwarn("THERE IS NOTHING TO READ 16 5 4") called at /usr/bin/isotovideo line 344
[2022-05-13T05:04:01.792490+02:00] [warn] !!! : THERE IS NOTHING TO READ 16 5 4
[2022-05-13T05:04:01.792691+02:00] [debug] stopping command server 1370 because test execution ended

VNC is complaining that it gets an unexpected end of data, but for me that looks quite normal, when the host is down, there is no VNC server running, so where should the data come from.

The autoinst-log.txt from the S390-KVM test looks quite different:

[2022-05-03T07:44:26.806619+02:00] [debug] assert_shutdown_with_soft_timeout(): soft_timeout=60
[2022-05-03T07:44:26.806865+02:00] [debug] tests/shutdown/shutdown.pm:16 called power_action_utils::power_action -> lib/power_action_utils.pm:331 called power_action_utils::assert_shutdown_with_soft_timeout -> lib/power_action_utils.pm:420 called testapi::check_shutdown
[2022-05-03T07:44:26.806990+02:00] [debug] <<< testapi::check_shutdown(timeout=60)
[2022-05-03T07:44:26.807782+02:00] [debug] <<< backend::baseclass::run_ssh_cmd(cmd="! virsh  dominfo openQA-SUT-6 | grep -w 'shut off'", wantarray=0, keep_open=1)
[2022-05-03T07:44:26.808002+02:00] [debug] <<< backend::baseclass::run_ssh(cmd="! virsh  dominfo openQA-SUT-6 | grep -w 'shut off'", keep_open=1, wantarray=0)
[2022-05-03T07:44:26.808131+02:00] [debug] <<< backend::baseclass::new_ssh_connection(keep_open=1, blocking=1, wantarray=0)
[2022-05-03T07:44:26.855827+02:00] [debug] Use existing SSH connection (key:hostname=s390zp18.suse.de,username=root,port=22)
[2022-05-03T07:44:26.898990+02:00] [debug] [run_ssh_cmd(! virsh  dominfo openQA-SUT-6 | grep -w 'shut off')] exit-code: 0
[2022-05-03T07:44:27.900433+02:00] [debug] <<< backend::baseclass::run_ssh_cmd(cmd="! virsh  dominfo openQA-SUT-6 | grep -w 'shut off'", wantarray=0, keep_open=1)
[2022-05-03T07:44:27.900626+02:00] [debug] <<< backend::baseclass::run_ssh(cmd="! virsh  dominfo openQA-SUT-6 | grep -w 'shut off'", wantarray=0, keep_open=1)
[2022-05-03T07:44:27.900757+02:00] [debug] <<< backend::baseclass::new_ssh_connection(blocking=1, keep_open=1, wantarray=0)
[2022-05-03T07:44:27.945994+02:00] [debug] Use existing SSH connection (key:hostname=s390zp18.suse.de,username=root,port=22)

Interesting point is that here the backend starts running ssh commands after check_shutdown.

Actions #4

Updated by geor almost 2 years ago

Just adding this as a comment, I tested manually shutting down from GUI in z/VM in a system installed with the GMC image. It works as intended, clicking, power off popup, authentication required popup and then shuts down without issues.

Actions #5

Updated by JERiveraMoya almost 2 years ago

Please remove the soft-failure and replace it with record_info.
Additionally you could consider to put this ticket in @qa-tools squad backlog providing fresh verification with logs.

Actions #6

Updated by JERiveraMoya almost 2 years ago

  • Status changed from In Progress to Feedback
  • Priority changed from High to Normal
Actions #7

Updated by rainerkoenig over 1 year ago

PR#15176 to replace softfailure with just info.

Actions #8

Updated by JERiveraMoya over 1 year ago

  • Status changed from Feedback to In Progress

could we please add in the record info a ticket for tools teams to investigate?

Actions #9

Updated by rainerkoenig over 1 year ago

  • Status changed from In Progress to Resolved

Ticket will be further investigated in poo#114439.

Actions

Also available in: Atom PDF