Project

General

Profile

Actions

action #33340

closed

[tools][functional][u][medium][pvm] Enable graphical installation for the powerVM backend

Added by nicksinger over 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
New test
Target version:
SUSE QA - Milestone 22
Start date:
2018-03-15
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

The current implementation of the spvm backend can only install in textmode (reference).

This most likely happens because the initiated console from the powerVM backend is not correctly pass the $gui parameter to sshCommand (consoles/console.pm) with then in turn never adds "-X" to the ssh options. The resulting call of yast.ssh inside the SUT then opens the ncurses UI and not the graphical installer.

AC1: A cloned graphical job from OSD actually starts a graphical installer with the powerVM backend

Suggestion

Verify with WIP PR for powerVM in os-autoinst
Contact nsinger for details how to run tests on grenache


Related issues 3 (0 open3 closed)

Related to openQA Project - coordination #21838: [functional][u][saga] PowerVM backendClosednicksinger2017-08-082018-07-31

Actions
Blocked by openQA Tests - action #39785: [sle][functional][u][spvm][sporadic] test fails in grub_test - test stucks at powerVM SMS menuResolveddheidler2018-08-15

Actions
Copied to openQA Infrastructure - action #37372: [tools][pvm] powerVM production workerResolvednicksinger2018-03-15

Actions
Actions #1

Updated by nicksinger over 6 years ago

Actions #2

Updated by nicksinger over 6 years ago

  • Copied to action #33388: [functional][u][easy][pvm] Implement proper split from other backends added
Actions #3

Updated by nicksinger over 6 years ago

  • Copied to deleted (action #33388: [functional][u][easy][pvm] Implement proper split from other backends)
Actions #4

Updated by okurz over 6 years ago

  • Project changed from openQA Project to openQA Tests
  • Subject changed from [tools][functional][easy][pvm] Enable graphical installation for the powerVM backend to [tools][functional][u][easy][pvm] Enable graphical installation for the powerVM backend
  • Category set to New test
  • Target version set to Milestone 17

I think this is more driven by wanting to extend the test coverage therefore moving to the tests sub project. Also I set [u] because IMHO the [u] team can better handle special back ends although main part of installation will happen related to [yast]

Actions #5

Updated by okurz over 6 years ago

  • Due date set to 2018-07-03
  • Priority changed from Normal to High

There are high expectations on having the pvm backend in place, e.g. for SLE12SP4. We need to move forward a bit faster.

Actions #6

Updated by okurz over 6 years ago

Hm, shouldn't we start with a simple test, e.g. "memcheck", on the new backend?

@nicksinger could you please reference precursor tickets, e.g. from the tools team and what is the current situation?

It looks like we are missing even more tickets to have that whole story covered completely, e.g. at least two workers, salt recipes for worker config, etc.

Actions #7

Updated by okurz over 6 years ago

  • Copied to action #37372: [tools][pvm] powerVM production worker added
Actions #8

Updated by okurz over 6 years ago

  • Target version changed from Milestone 17 to Milestone 17
Actions #9

Updated by mgriessmeier over 6 years ago

  • Status changed from New to Workable
Actions #10

Updated by dheidler over 6 years ago

  • Assignee set to dheidler
Actions #11

Updated by riafarov over 6 years ago

  • Subject changed from [tools][functional][u][easy][pvm] Enable graphical installation for the powerVM backend to [tools][functional][u][medium][pvm] Enable graphical installation for the powerVM backend
  • Description updated (diff)
  • Priority changed from High to Urgent
Actions #12

Updated by dheidler over 6 years ago

  • Priority changed from Urgent to High
Actions #13

Updated by dheidler over 6 years ago

Looks like as if the sshCommand was not the problem.
The problem was, that the kernel commandline was wrong:

Wrong:

sshd=1 sshpassword=foobar

Right:

ssh=1 sshpassword=foobar

This resulted in the SUT to boot into text installation on the serial tty.
So there was not even an ssh to the SUT in the first place.

With ssh=1 the SUT boots up to the yast please connect via ssh message - then the test waits for a needle:
http://grenache-1.qa.suse.de/tests/140

I think here is some step missing that issues the ssh to yast and calls yast.ssh.

Actions #14

Updated by dheidler over 6 years ago

  • Status changed from Workable to In Progress
Actions #15

Updated by okurz over 6 years ago

dheidler wrote:

The problem was, that the kernel commandline was wrong:

Wrong:

sshd=1 sshpassword=foobar

There might have been a different intention. "sshd=1" means start an additional ssh server but do not run the installation over SSH. This approach is also used e.g. for s390x-z/VM for VNC based installations where we additionally still want to have a terminal connection to the SUT, e.g. to execute shell commands to collect logs.

Actions #16

Updated by mgriessmeier over 6 years ago

  • Due date changed from 2018-07-03 to 2018-07-31
Actions #17

Updated by okurz over 6 years ago

  • Priority changed from High to Urgent
Actions #18

Updated by okurz over 6 years ago

  • Copied to action #38513: [functional][u][pvm] Have any test scenario showing up with useful test results conducted on pvm backend triggered as part of SLE12SP4 validation tests added
Actions #19

Updated by okurz over 6 years ago

  • Copied to deleted (action #38513: [functional][u][pvm] Have any test scenario showing up with useful test results conducted on pvm backend triggered as part of SLE12SP4 validation tests)
Actions #20

Updated by okurz over 6 years ago

  • Due date changed from 2018-07-31 to 2018-08-28
  • Status changed from In Progress to Workable
  • Assignee deleted (dheidler)
  • Priority changed from Urgent to Normal
  • Target version changed from Milestone 17 to Milestone 18

As discussed during sprint planning meeting, let's focus on #38513 first

Actions #21

Updated by okurz over 6 years ago

Actions #22

Updated by okurz over 6 years ago

Actions #23

Updated by okurz over 6 years ago

  • Due date changed from 2018-08-28 to 2018-09-25
  • Target version changed from Milestone 18 to Milestone 19
Actions #24

Updated by zluo about 6 years ago

  • Status changed from Workable to Blocked

we need to handle #37372 at first.

Actions #25

Updated by okurz about 6 years ago

  • Status changed from Blocked to Workable

No, we don't. Please do not set any ticket to blocked without assignee to track if the blocked status is resolved. You could add tickets with the relation "blocking" though.

Actions #26

Updated by okurz about 6 years ago

  • Due date changed from 2018-09-25 to 2018-10-23
  • Target version changed from Milestone 19 to Milestone 20
Actions #27

Updated by okurz about 6 years ago

  • Target version changed from Milestone 20 to future

ok, I would like to see the one production worker in place first, see #37372

Actions #28

Updated by okurz about 6 years ago

  • Due date deleted (2018-10-23)
Actions #29

Updated by okurz about 6 years ago

  • Blocked by action #39785: [sle][functional][u][spvm][sporadic] test fails in grub_test - test stucks at powerVM SMS menu added
Actions #30

Updated by okurz about 6 years ago

  • Status changed from Workable to Blocked
  • Assignee set to okurz
Actions #31

Updated by okurz almost 6 years ago

  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)
  • Target version changed from future to Milestone 22
Actions #32

Updated by zluo almost 6 years ago

  • Status changed from Workable to In Progress
  • Assignee set to zluo

check this now...

Actions #33

Updated by zluo almost 6 years ago

http://f40.suse.de/tests/54/file/autoinst-log.txt shows issue with remote spvm worker atm.

Actions #34

Updated by mgriessmeier almost 6 years ago

  • Assignee changed from zluo to mgriessmeier

zluo wrote:

http://f40.suse.de/tests/54/file/autoinst-log.txt shows issue with remote spvm worker atm.

disk space on shared-workers was cleaned up manually
-> https://gitlab.suse.de/qa-sle/shared-development-worker/merge_requests/18 for solving this in the future (or we should increase the disk size)

I want to try this ticket out today, hope you don't mind

Actions #35

Updated by mgriessmeier almost 6 years ago

  • Status changed from In Progress to Feedback

WIP PR created: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6470
Verification runs and crosschecks of regressions still in progress

Next steps:

  • Create and enable ssh-x testmodule for spvm on o.s.d (first in testdev group and later move to functional)

putting to feedback for now

Actions #36

Updated by mgriessmeier almost 6 years ago

  • Status changed from Feedback to In Progress

so after looking on the finished verification runs, we face two issues:

  • on ssh-X the installation itself took longer than 2000s, so rebootnow needle didn't match
  • on ssh-text we might need to adapt the new console handling also for the reboot process

I will take a look on both

Actions #37

Updated by mgriessmeier almost 6 years ago

  • Status changed from In Progress to Feedback

Console handling to reconnect the management console got unified, PR was updated
too long installation on graphical is still under investigation, most likely product issue

Actions #38

Updated by mgriessmeier almost 6 years ago

bsc opened for slow ssh-X installation: https://bugzilla.suse.com/show_bug.cgi?id=1121085

Actions #39

Updated by mgriessmeier almost 6 years ago

  • Status changed from Feedback to Resolved

test works on o.s.d in test development: https://openqa.suse.de/tests/2374931
moved to functional and triggered for build 137.1: https://openqa.suse.de/tests/2375290

-> resolved

Actions

Also available in: Atom PDF