action #52313
closed
- Copied from action #52310: [functional][y] Enable remote installation over VNC for openSUSE added
- Description updated (diff)
- Status changed from New to Workable
- Estimated time set to 5.00 h
- Status changed from Workable to In Progress
- Assignee set to JERiveraMoya
- Status changed from In Progress to Feedback
- Status changed from Feedback to Blocked
- 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.
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.
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.
- Due date changed from 2019-08-13 to 2019-07-30
- Due date changed from 2019-07-30 to 2019-08-13
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.
- Description updated (diff)
- Estimated time set to 13.00 h
- Due date changed from 2019-08-13 to 2019-08-27
- Target version changed from Milestone 26 to Milestone 27
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.
- Status changed from Workable to In Progress
- Assignee set to JERiveraMoya
- Status changed from In Progress to Feedback
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.
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.
- Status changed from Feedback to Resolved
I will create follow-up ticket for the remaining part and we will discuss tomorrow.
- Copied to action #56006: [functional][y][Timebox:24] Fix remote installation over ssh for openSUSE added
- Copied to deleted (action #56006: [functional][y][Timebox:24] Fix remote installation over ssh for openSUSE)
Also available in: Atom
PDF