action #33340
closed[tools][functional][u][medium][pvm] Enable graphical installation for the powerVM backend
Added by nicksinger about 6 years ago. Updated over 5 years ago.
0%
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
Updated by nicksinger about 6 years ago
- Blocks coordination #21838: [functional][u][saga] PowerVM backend added
Updated by nicksinger about 6 years ago
- Copied to action #33388: [functional][u][easy][pvm] Implement proper split from other backends added
Updated by nicksinger about 6 years ago
- Copied to deleted (action #33388: [functional][u][easy][pvm] Implement proper split from other backends)
Updated by okurz about 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]
Updated by okurz almost 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.
Updated by okurz almost 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.
Updated by okurz almost 6 years ago
- Copied to action #37372: [tools][pvm] powerVM production worker added
Updated by okurz almost 6 years ago
- Target version changed from Milestone 17 to Milestone 17
Updated by riafarov almost 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
Updated by dheidler almost 6 years ago
- Priority changed from Urgent to High
Rebased old PRs from coolo: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5272
Updated by dheidler almost 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.
Updated by dheidler almost 6 years ago
- Status changed from Workable to In Progress
Updated by okurz almost 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.
Updated by mgriessmeier almost 6 years ago
- Due date changed from 2018-07-03 to 2018-07-31
Updated by okurz almost 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
Updated by okurz almost 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)
Updated by okurz almost 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
Updated by okurz over 5 years ago
- Blocks deleted (coordination #21838: [functional][u][saga] PowerVM backend)
Updated by okurz over 5 years ago
- Related to coordination #21838: [functional][u][saga] PowerVM backend added
Updated by okurz over 5 years ago
- Due date changed from 2018-08-28 to 2018-09-25
- Target version changed from Milestone 18 to Milestone 19
Updated by zluo over 5 years ago
- Status changed from Workable to Blocked
we need to handle #37372 at first.
Updated by okurz over 5 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.
Updated by okurz over 5 years ago
- Due date changed from 2018-09-25 to 2018-10-23
- Target version changed from Milestone 19 to Milestone 20
Updated by okurz over 5 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
Updated by okurz over 5 years ago
- Blocked by action #39785: [sle][functional][u][spvm][sporadic] test fails in grub_test - test stucks at powerVM SMS menu added
Updated by okurz over 5 years ago
- Status changed from Workable to Blocked
- Assignee set to okurz
Updated by okurz over 5 years ago
- Status changed from Blocked to Workable
- Assignee deleted (
okurz) - Target version changed from future to Milestone 22
Updated by zluo over 5 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
check this now...
Updated by zluo over 5 years ago
http://f40.suse.de/tests/54/file/autoinst-log.txt shows issue with remote spvm worker atm.
Updated by mgriessmeier over 5 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
Updated by mgriessmeier over 5 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
Updated by mgriessmeier over 5 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
Updated by mgriessmeier over 5 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
Updated by mgriessmeier over 5 years ago
bsc opened for slow ssh-X installation: https://bugzilla.suse.com/show_bug.cgi?id=1121085
Updated by mgriessmeier over 5 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