Project

General

Profile

Actions

action #52313

closed

[functional][y] Enable remote installation over ssh for openSUSE

Added by riafarov almost 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
New test
Target version:
SUSE QA - Milestone 27
Start date:
2019-05-29
Due date:
2019-08-27
% Done:

0%

Estimated time:
13.00 h
Difficulty:

Description

See parent ticket for the motivation.

Acceptance criteria

  1. Remote installation over ssh is tested on o3 for Leap and TW
  2. New test suite is added to the development job group first, once proven to be stable is moved to the main job group

Suggestions

Use SLES remote_ssh_controller and remote_ssh_target_nfs test suites as a base.
See https://openqa.suse.de/tests/latest?test=remote_ssh_controller&machine=64bit&flavor=Installer-DVD&distri=sle&arch=x86_64&version=15-SP1
https://openqa.suse.de/tests/latest?arch=x86_64&version=15-SP1&test=remote_ssh_target_ftp&machine=64bit&distri=sle&flavor=Installer-DVD

There is worker class tap.
riafarov has access to the machine, so candidate to pair up.
Setup should just work, so fixing is out of scope.

We need to create support_server image which works with dhcp and dns roles.
Secondly, we will have to adjust code for the network configuration which works with wicked as we have NetworkManager.
Alternative will be to get images which have wicked.

For the development we can trigger support_server as normal (not MM test) and once everything works there, we can trigger it as a part of MM test.


Related issues 1 (0 open1 closed)

Copied from openQA Tests - action #52310: [functional][y] Enable remote installation over VNC for openSUSEResolvedybonatakis2019-05-292020-01-14

Actions
Actions #1

Updated by riafarov almost 5 years ago

  • Copied from action #52310: [functional][y] Enable remote installation over VNC for openSUSE added
Actions #2

Updated by riafarov almost 5 years ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Estimated time set to 5.00 h
Actions #3

Updated by JERiveraMoya over 4 years ago

  • Status changed from Workable to In Progress
  • Assignee set to JERiveraMoya
Actions #4

Updated by JERiveraMoya over 4 years ago

  • Status changed from In Progress to Feedback
Actions #5

Updated by JERiveraMoya over 4 years ago

  • Status changed from Feedback to Blocked
Actions #6

Updated by riafarov over 4 years ago

  • Due date changed from 2019-07-16 to 2019-08-13
  • Status changed from Blocked to Workable
  • Assignee deleted (JERiveraMoya)
  • Estimated time deleted (5.00 h)

Same story as in #37045, we need to create image for the support server, adjust code for the network configuration which is wicked specific and then it should be feasible to execute the test.

Actions #7

Updated by okurz over 4 years ago

riafarov wrote:

Same story as in #37045, we need to create image for the support server

keep in mind that you actually do not need to create any support server but have a "controller" and a "target" scenario as you already described in the description.

Actions #8

Updated by riafarov over 4 years ago

okurz wrote:

riafarov wrote:

Same story as in #37045, we need to create image for the support server

keep in mind that you actually do not need to create any support server but have a "controller" and a "target" scenario as you already described in the description.

Controller is actually support server with gnome in case of SLES. So we need image for that, as I guess we should not reuse SLES images and make them public.

Actions #9

Updated by riafarov over 4 years ago

  • Due date changed from 2019-08-13 to 2019-07-30
Actions #10

Updated by riafarov over 4 years ago

  • Due date changed from 2019-07-30 to 2019-08-13
Actions #11

Updated by okurz over 4 years ago

riafarov wrote:

Controller is actually support server with gnome in case of SLES. So we need image for that, as I guess we should not reuse SLES images and make them public.

That's true. There are some tests though that already use a rather static qcow image, e.g. the rescue_system and external_iso ones so maybe these can be reused.

Actions #12

Updated by riafarov over 4 years ago

  • Description updated (diff)
  • Estimated time set to 13.00 h
Actions #13

Updated by JERiveraMoya over 4 years ago

  • Due date changed from 2019-08-13 to 2019-08-27
Actions #14

Updated by riafarov over 4 years ago

  • Target version changed from Milestone 26 to Milestone 27
Actions #15

Updated by okurz over 4 years ago

I removed the scenario remote_ssh_target_ftp and remote_ssh_controller from o3 as it consistently incompletes with:

[2019-08-14T15:03:07.973 CEST] [debug] usingenv VIDEOMODE=text
File '/var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/lib/../schedule/yast/remote_ssh_target.yaml' does not exist at /var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/lib/scheduler.pm line 98.

also there is a warning about

Use of uninitialized value in pattern match (m//) at /var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/lib/utils.pm line 912.

Please understand that we – the QA tools team – are looking for the reasons for all incomplete tests now in #54902 and this is why I encountered this failing test scenario. Please readd only after ensuring that the prerequisites are fulfilled.

Actions #16

Updated by JERiveraMoya over 4 years ago

  • Status changed from Workable to In Progress
  • Assignee set to JERiveraMoya
Actions #17

Updated by JERiveraMoya over 4 years ago

Picking image opensuse-42.1-x86_64-GM-gnome@64bit_cirrus.qcow2 we have an static image with gnome in opensuse that has as default wicked.
root-virtio-terminal does not work for this image so I have to force root-console for the moment: http://rivera-workstation.suse.cz/tests/101#step/login/6
Adding the correct pattern with zypper_call("in -t pattern dhcp_dns_server"); the support server seems to be ok and test run until the mutex section: http://rivera-workstation.suse.cz/tests/107#

Actions #18

Updated by JERiveraMoya over 4 years ago

  • Status changed from In Progress to Feedback

Finally root-virtio-terminal works with more recent image available having Wicked Service as well (opensuse-42.3-x86_64-GM-gnome@64bit.qcow2):
PR: Enable support server for ssh installation in opensuse

Actions #21

Updated by JERiveraMoya over 4 years ago

Tested further ideas to cut the corners and workaround the problems with the consoles:
1 - Select xterm on remote_controller.
We cannot use similar code than for vnc with:

select_console 'root-console';
send_key('alt-f7', 10);
x11_start_program('xterm');

https://openqa.opensuse.org/tests/1014890#step/remote_controller/12 fails due to it cannot switch to root-console and when I tried with the virtio-console, it complains that send_key is not allowed and then I tried type command, but it still in the desktop so, no-go for this path.

2 - Use the image for support server in O3 temporarily to see what happens: after thinking about it, it doesn't make sense due to I could only test in local and in local it is already working fine with Leap image. Testing in O3 would require create sle needles there (and delete them after) and upload an image with someone else's permissions, probably not worth it.

3 - Use Leap 42.1 as support server (it requires MACHINE=64bit_cirrus QEMUVGA=cirrus to display properly the screen and match existing needles):

login incorrect with virtio-console. Setting VIRTIO_CONSOLE=0 automation go by default to root-console and succeeds https://openqa.opensuse.org/tests/1014970#step/remote_controller/13. This might work in fact, and seems to work as well with xterm, I think I thought it was not working because perhaps I was not using the right params for cirrus and not setting to 0 virtio-console. Updating PR.

Actions #22

Updated by JERiveraMoya over 4 years ago

I retriggered test suites without VIDEOMODE and with VIDEOMODE=ssh-x, there is not difference so it seems that we are in the good track and we just need re-needling the installation due to it has different fonts, perhaps in another ticket if not completed at the end of the sprint.

Actions #23

Updated by JERiveraMoya over 4 years ago

PR: Fix remote_ssh_controller yaml for opensuse -> Merged
PR: Fix remote_ssh_controller.yaml -> Merged
I had to do in this ugly step-by-step way even merging myself PRs (guilty as charged this time) so I could reduce the load of work in some potential follow-up ticket picked by someone only to create lovely needles.

Actions #24

Updated by JERiveraMoya over 4 years ago

Mostly done all needles, although hits this error related with installation media: https://openqa.opensuse.org/tests/1017908

Actions #25

Updated by riafarov over 4 years ago

  • Status changed from Feedback to Resolved

I will create follow-up ticket for the remaining part and we will discuss tomorrow.

Actions #26

Updated by riafarov over 4 years ago

  • Copied to action #56006: [functional][y][Timebox:24] Fix remote installation over ssh for openSUSE added
Actions #27

Updated by riafarov about 4 years ago

  • Copied to deleted (action #56006: [functional][y][Timebox:24] Fix remote installation over ssh for openSUSE)
Actions

Also available in: Atom PDF