Project

General

Profile

Actions

action #122218

closed

coordination #121858: [epic] Automation of YaST in Container

Automate YaST Control Center in ALP

Added by JERiveraMoya over 1 year ago. Updated 10 months ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
Start date:
2022-12-20
Due date:
% Done:

0%

Estimated time:

Description

Motivation

For this first iteration, Yam squad will implement the steps needed to open YaST Control Center in ncurses.
This action will ensure at least that the workload can be open. Further actions will be tackle in the future.

Acceptance criteria

AC1: Use yast-mgmt-ncurses-test-api-container which contains libyui-rest-api
AC2: Make basic assertion that YaST Control Center is there using libyui-rest-api
AC3: For your libyui-rest-api model, do not use Controllers, just pages
AC4: Map all the menus and submenus offered for future use
AC5: Enable in all places where was configured in #128117

Additional information

ALP job group in openSUSE:
https://openqa.opensuse.org/group_overview/108
https://openqa.opensuse.org/group_overview/109

Knowledge base

Links that should be useful:


Files

screenshot-yast-control-center-ncurses.png (49.1 KB) screenshot-yast-control-center-ncurses.png Screenshot YaST ncurses container rainerkoenig, 2023-05-04 13:12
json-dumps.tgz (2.29 KB) json-dumps.tgz rainerkoenig, 2023-05-04 13:23

Related issues 2 (0 open2 closed)

Related to qe-yam - action #128117: Enable automation for YaST in Container in ALP in O3.Resolvedshukui2022-12-20

Actions
Related to qe-yam - action #130384: Enable automation for YaST in Container in ALP in OSDResolvedtinawang1232023-06-05

Actions
Actions #1

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #2

Updated by JERiveraMoya about 1 year ago

  • Description updated (diff)
Actions #3

Updated by geor about 1 year ago

  • Assignee set to geor
Actions #4

Updated by JERiveraMoya about 1 year ago

  • Description updated (diff)
Actions #5

Updated by JERiveraMoya about 1 year ago

  • Description updated (diff)

Please file a bug for ALP for "When selecting a menu item on the left with REST API, the change event is not sent to the central UI element". So basically one YSelectionBox doesn't send the event of change to the other YSelectionBox in the screen.
We should create a design that do not need to be reworked by the next person, only to remove the workaround, so I'd suggest to avoid needle and do something like:
1 - select item with REST API
2 - send shift-tab to put the focus on the menu selection
3 - send up + send down

Therefore when the bug is fixed we can remove easily steps 2 and 3.

Actions #6

Updated by JERiveraMoya about 1 year ago

  • Description updated (diff)
Actions #7

Updated by geor about 1 year ago

  • Status changed from Workable to In Progress
Actions #8

Updated by JERiveraMoya about 1 year ago

did you have the chance to file the bug? (in case it could be fixed early that we could think)

Actions #9

Updated by JERiveraMoya about 1 year ago

  • Subject changed from Create new test suite to start YaST Control center in ALP to Automate YaST Control center in ALP
Actions #10

Updated by JERiveraMoya about 1 year ago

  • Subject changed from Automate YaST Control center in ALP to Automate YaST Control Center in ALP
Actions #12

Updated by geor about 1 year ago

JERiveraMoya wrote:

Please file a bug for ALP for "When selecting a menu item on the left with REST API, the change event is not sent to the central UI element". So basically one YSelectionBox doesn't send the event of change to the other YSelectionBox in the screen.
We should create a design that do not need to be reworked by the next person, only to remove the workaround, so I'd suggest to avoid needle and do something like:
1 - select item with REST API
2 - send shift-tab to put the focus on the menu selection
3 - send up + send down

Therefore when the bug is fixed we can remove easily steps 2 and 3.

I am not sure I can reproduce this bug. What would you say is happening vs what would we expect?

Actions #13

Updated by geor about 1 year ago

JERiveraMoya wrote:

Please file a bug for ALP for "When selecting a menu item on the left with REST API, the change event is not sent to the central UI element". So basically one YSelectionBox doesn't send the event of change to the other YSelectionBox in the screen.
We should create a design that do not need to be reworked by the next person, only to remove the workaround, so I'd suggest to avoid needle and do something like:
1 - select item with REST API
2 - send shift-tab to put the focus on the menu selection
3 - send up + send down

Therefore when the bug is fixed we can remove easily steps 2 and 3.

bug filed: https://bugzilla.suse.com/show_bug.cgi?id=1206966

Actions #14

Updated by JERiveraMoya about 1 year ago

good news! this one is fixed https://bugzilla.suse.com/show_bug.cgi?id=1206929#c5, so no need to invest on needles or shortcuts when accessing modules through the control center, we will just need to handle that condition of connection denied in those transitions.

Regarding the firewall, I plan other ticket where the automation will enable the firewall and open only libyui-rest-api port, so for this ticket what we could do is just as a setup of the test, stop the firewall (we can leave the exact port for the other test to do it).

Actions #15

Updated by leli about 1 year ago

It's not related with build.

Actions #16

Updated by JERiveraMoya about 1 year ago

  • Status changed from In Progress to Workable
  • Assignee deleted (geor)
Actions #17

Updated by JERiveraMoya about 1 year ago

  • Tags set to qe-yam-refinement
  • Target version deleted (Current)
Actions #18

Updated by JERiveraMoya about 1 year ago

  • Target version set to Current
Actions #19

Updated by JERiveraMoya about 1 year ago

  • Target version deleted (Current)
Actions #20

Updated by JERiveraMoya 12 months ago

  • Tags deleted (qe-yam-refinement)
  • Priority changed from Normal to High
  • Target version set to Current
Actions #21

Updated by JERiveraMoya 11 months ago

  • Description updated (diff)
Actions #22

Updated by JERiveraMoya 11 months ago

  • Related to action #128117: Enable automation for YaST in Container in ALP in O3. added
Actions #23

Updated by JERiveraMoya 11 months ago

  • Description updated (diff)
Actions #24

Updated by JERiveraMoya 11 months ago

  • Description updated (diff)
Actions #25

Updated by rainerkoenig 11 months ago

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

Updated by JERiveraMoya 11 months ago

Please sync with @shukui in #128117

Actions #27

Updated by rainerkoenig 11 months ago

  • Description updated (diff)
Actions #29

Updated by rainerkoenig 11 months ago

Structure analysis

Screenshot YaST ncurses container

The ncurses interface consists of 2 selection boxes.

  • Left side: group selection with "id" : "groups"
  • Right side: program selection with "id" : "progs"

The attachment json-dumps.tgz holds all collected JSON information for each of the groups.

So launching programs from control center is a two step process by selecting the group and the program and then "click" on the Run button.

Actions #30

Updated by JERiveraMoya 11 months ago

yes, next step would be to design your POMs, actually for this first iteration we could only have one Page Object Model representing the whole screen.
The test would look like:

ycc = get_yast_control_center();

ycc->run_online_updates()
...
ycc->run_software_repositories()
...

From the functional point of view it doesn't matter the selections, but the full action to Run at YaST module, so in the Page level you would have:

# all possible ids
...
# private methods (we could use for example underscore to distinguish them)
sub _select_software { ... };
sub _select_online_updates { ... };
sub _run { ... };

# methods
sub run_online_updates {
  _select_software();
  _select_online_updates();
  _run();
}

I believe we should start by having only one, because once you will install a package with transactional server the YaST Control Center will have a new itema to select and perhaps in a new section, so we will need to have a different POM, in order to reuse code we will need to do composition and break down the suggested above POM, so we can minimize the number of changes in the future as well. But until we don't have such a scenario we can leave it in single one.

Let's discuss if you have more idea.

Actions #31

Updated by JERiveraMoya 11 months ago

Edited comment above about potential POM design.

Actions #32

Updated by JERiveraMoya 11 months ago

See note-13
Faced bug https://bugzilla.suse.com/show_bug.cgi?id=1206966 still not fixed.
Please proceed with some workaround to go on.

Actions #34

Updated by rainerkoenig 11 months ago

Updated the PR with the comments from the first review. PR is still in WIP.

Actions #35

Updated by rainerkoenig 11 months ago

First draft of a test module posted to PR.

Actions #36

Updated by rainerkoenig 10 months ago

Schrödinger's YuiRestClient?

Still struggling with my test module.

If I use use base 'basetest'; in my test module I get far, but the log still shows warnings like

Use of uninitialized value in hash element at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/Log.pm line 75.
    Mojo::Log::debug(Mojo::Log=HASH(0x5623608d15b8), "Finding widget by url: http://localhost:39098/v1/widgets?labe"...) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Logger.pm line 25
    YuiRestClient::Logger::debug(YuiRestClient::Logger=HASH(0x5623604b90b0), "Finding widget by url: http://localhost:39098/v1/widgets?labe"...) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Http/WidgetController.pm line 55
    YuiRestClient::Http::WidgetController::find(YuiRestClient::Http::WidgetController=HASH(0x562360a7b098), HASH(0x5623608bd2b0)) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 56
    YuiRestClient::Widget::Base::find_widgets(YuiRestClient::Widget::Label=HASH(0x562360d7e1d8), undef) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 31
    eval {...} called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 31
    YuiRestClient::Widget::Base::exist(YuiRestClient::Widget::Label=HASH(0x562360d7e1d8)) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/Yam/ControlCenterPage.pm line 28

and the code complains that the page is not shown.

If I use use base 'y2_installbase'; in my test module then things get really worse:

# Test died: Can't call method "append" on an undefined value at /var/lib/openqa/pool/9/os-autoinst-distri-opensuse/lib/YuiRestClient/Logger.pm line 30.
    YuiRestClient::Logger::info("YuiRestClient::Logger", "yast2_control_center test module started") called at /var/lib/openqa/pool/9/os-autoinst-distri-opensuse/lib/y2_base.pm line 173
    y2_base::pre_run_hook(yast2_control_center=HASH(0x55693d195b68)) called at /usr/lib/os-autoinst/basetest.pm line 334

The call it complains about is in the pre_run_hook and calls YuiRestClient::Logger->info() when YUI_REST_API is set to 1. But of course, if I want to use libyui, this needs to beconfigured, otherwise things like setup_libyui_running_system complain.

That makes me think that YuiRestClient::Logger is not initialized, even with setup_libyui_running_system before this test module. So I'm missing something, but what?

Actions #37

Updated by leli 10 months ago

rainerkoenig wrote:

Schrödinger's YuiRestClient?

Still struggling with my test module.

If I use use base 'basetest'; in my test module I get far, but the log still shows warnings like

Use of uninitialized value in hash element at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/Log.pm line 75.

You can try to add this line in your test code:
my $instance = YuiRestClient::init_logger->get_instance();
I remembered we have the same warning info at first, then fixed it with the line.
And maybe you can refer to my branch (https://github.com/os-autoinst/os-autoinst-distri-opensuse/compare/master...lemon-suse:os-autoinst-distri-opensuse:firewall-libyui-page-base-on-alp?expand=1).

Mojo::Log::debug(Mojo::Log=HASH(0x5623608d15b8), "Finding widget by url: http://localhost:39098/v1/widgets?labe"...) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Logger.pm line 25
YuiRestClient::Logger::debug(YuiRestClient::Logger=HASH(0x5623604b90b0), "Finding widget by url: http://localhost:39098/v1/widgets?labe"...) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Http/WidgetController.pm line 55
YuiRestClient::Http::WidgetController::find(YuiRestClient::Http::WidgetController=HASH(0x562360a7b098), HASH(0x5623608bd2b0)) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 56
YuiRestClient::Widget::Base::find_widgets(YuiRestClient::Widget::Label=HASH(0x562360d7e1d8), undef) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 31
eval {...} called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/YuiRestClient/Widget/Base.pm line 31
YuiRestClient::Widget::Base::exist(YuiRestClient::Widget::Label=HASH(0x562360d7e1d8)) called at /var/lib/openqa/pool/8/os-autoinst-distri-opensuse/lib/Yam/ControlCenterPage.pm line 28

and the code [complains that the page is not shown](https://openqa.opensuse.org/tests/3307999#step/yast2_control_center/3). 

If I use `use base 'y2_installbase';` in my test module then [things get really worse](https://openqa.opensuse.org/tests/3308213#step/yast2_control_center/2):

Test died: Can't call method "append" on an undefined value at /var/lib/openqa/pool/9/os-autoinst-distri-opensuse/lib/YuiRestClient/Logger.pm line 30.

YuiRestClient::Logger::info("YuiRestClient::Logger", "yast2_control_center test module started") called at /var/lib/openqa/pool/9/os-autoinst-distri-opensuse/lib/y2_base.pm line 173
y2_base::pre_run_hook(yast2_control_center=HASH(0x55693d195b68)) called at /usr/lib/os-autoinst/basetest.pm line 334

The call it complains about is in the pre_run_hook and calls `YuiRestClient::Logger->info()` when YUI_REST_API is set to 1. But of course, if I want to use libyui, this needs to beconfigured, otherwise things like `setup_libyui_running_system` complain. 

That makes me think that `YuiRestClient::Logger` is not initialized, even with `setup_libyui_running_system` before this test module. So I'm missing something, but what?
Actions #38

Updated by rainerkoenig 10 months ago

Status update

  • Initializing the logger in products/alp/main.pm solved the problems with use 'y2_installbase
  • Verifcation run now does what I expect at this stage of development (we're stilL WIP)
  • Next action is to act with the control center and then exit it
Actions #39

Updated by rainerkoenig 10 months ago

Made a VR in the Development ALP Bedrock job group based on the settings provided by Shu Kui's PR.

Actions #40

Updated by rainerkoenig 10 months ago

  • Status changed from In Progress to Resolved
Actions #41

Updated by rainerkoenig 10 months ago

  • Status changed from Resolved to In Progress
Actions #42

Updated by JERiveraMoya 10 months ago

  • Related to action #130384: Enable automation for YaST in Container in ALP in OSD added
Actions #43

Updated by JERiveraMoya 10 months ago

  • Status changed from In Progress to Resolved

Let's resolve this ticket, in the related ticket we will add your work, but for now SLE ALP looks quite broken in openQA, it might take a while.

Actions

Also available in: Atom PDF