QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Compared the passed job : https://openqa.suse.de/tests/14611766#step/yast2_lan_restart_bond/44, the root cause for this issue may for the bondport hasn't shown as br1, https://openqa.suse.de/tests/15355275#step/yast2_lan_restart_bond/53
I will try to download the iso: http://openqa.suse.de/tests/15398123/asset/iso/SLE-15-SP7-Online-x86_64-Build14.1-Media1.iso to manually reproduce it.

Still can't fix the issue through add more waittime before send next key, https://openqa.suse.de/tests/15424608#step/yast2_lan_restart_bond/47

I think this may related with the edit the bonding while not wait and send next key which caused yast2 vlan still run something in backend which caused later send cancel key but no response. But I can't reproduce the issue manually. I will try to simulate the steps as openQA in manual test(edit bonding and click next quickly).

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_gui
https://openqa.suse.de/tests/15547046#step/yast2_security/1

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_gui
https://openqa.suse.de/tests/15749904#step/yast2_lan_restart_bond/1

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 56 days if nothing changes in this ticket.

I had a very deep look into this issue and I think it is a problem of libyui connection being lost.

If you look at the code of the test module:

sub run {
    record_info('bond', 'Verify network is not restarted after saving bond device settings without changes.');
    open_network_settings;
    $network_settings->view_bond_slave_without_editing();
    $network_settings->cancel_changes();
    $network_settings->accept_all_changes_will_be_lost();
    wait_for_xterm_to_be_visible();
    check_network_status('no_restart_or_reload', 'bond');
}

The error occurs after we were in $network_settings->view_bond_slave_without_editing(); and the next action would be to cancel the changes by pressing the cancel button.
$network_settings->cancel_changes(); does this by using libyui. This is reflected in the yui-log.txt:

354 [2024-11-27T16:35:28.615769+01:00] [info] [pid:5025] yast2_lan_restart_bond test module started
355 [2024-11-27T16:35:53.693803+01:00] [debug] [pid:5025] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=abort
356 [2024-11-27T16:40:55.899238+01:00] [debug] [pid:5025] Check connection to the app by url: http://localhost:39091/v1/widgets

Also see that the error message in the test module just says "timed out" and we see in the yui-log.txt above, that we don't get a "widget not found" message, but a check for the conneciton to the YUI REST API.

Since it is almost impossible to debug the code at this point I just hacked the code for a proof of concept by inserting a send_key 'alt-c' after we pressed next, so practically doing the job of libyui at this point. The test still fails because i didn't remove the line that sends the cancel by libyui, but in the test I see that we now progress to that popup that asks if we reaqlly want to abort. And as another evidence that there is something wrong our pressing of the cancel-key by libyui now prodcuces these lines in the yui-log.txt:

353 [2024-12-03T09:26:10.338059+01:00] [debug] [pid:23379] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=abort
354 [2024-12-03T09:26:11.354963+01:00] [error] [pid:23379] Widget not found by url: http://localhost:39091/v1/widgets?action=press&id=abort

The line with "Widget not found" is repeated several times then until we proceed to check the connection. But the error displayed in the details is now "Widget not found".

So the current conclusion for the root cause of this problem is that we suffer from a temporary connection loss to the YUI_REST_API server component . Therefore the pressing of the "Cancel" button by using libyui times out and the test fails.

Unfortunately there is no yui-log.txt available for previous service packs to see how this test performed in the past, where this test passed.

Next attempt to find out what is going on. Assuming that the problem is that we shoot an action at a widget that is not fully loaded I remembered those nice is_shown() methods in other pages and controllers. So I tried a proof of concept by modifying the code for sending the cancel action:

sub press_cancel {
    my ($self) = @_;
    if ($self->{btn_cancel}->exist()) {
        $self->{btn_cancel}->click();
    }
}

So the idea is that we check if the widget is there before sending the cancel action. Easy, straightforward.

Then I did a VR with this and looked at the yui-log.txt:

[2024-12-03T18:10:59.496821+01:00] [info] [pid:8221] yast2_lan_restart_bridge test module started
[2024-12-03T18:11:24.760087+01:00] [debug] [pid:8221] Finding widget by url: http://localhost:39091/v1/widgets?id=abort
[2024-12-03T18:11:25.767189+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=abort
[2024-12-03T18:11:26.776753+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=yes
[2024-12-03T18:12:19.558280+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=next
[2024-12-03T18:14:09.929219+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=next
[2024-12-03T18:14:48.238795+01:00] [info] [pid:8221] yast2_lan_restart_vlan test module started
[2024-12-03T18:15:09.294121+01:00] [debug] [pid:8221] Finding widget by url: http://localhost:39091/v1/widgets?id=abort
[2024-12-03T18:15:10.300199+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=abort
[2024-12-03T18:15:11.305116+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=yes
[2024-12-03T18:16:00.901110+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=next
[2024-12-03T18:18:01.827472+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=next

You see, perfect matches, first "Finding widget with id=abort" then "sending action with id=abort". For both ast2_lan_restart_bridge and yast2_lan_restart_vlan test.

Now lets look at the critical part in yast2_lan_restart_bond:

[2024-12-03T18:18:35.146597+01:00] [info] [pid:8221] yast2_lan_restart_bond test module started
[2024-12-03T18:19:00.195501+01:00] [debug] [pid:8221] Finding widget by url: http://localhost:39091/v1/widgets?id=abort
[2024-12-03T18:24:02.304724+01:00] [debug] [pid:8221] Sending action to widget by url: http://localhost:39091/v1/widgets?action=press&id=yes
[2024-12-03T18:25:19.564077+01:00] [debug] [pid:8221] Check connection to the app by url: http://localhost:39091/v1/widgets

"Finding widget with id=abort" and then "Sending action with id=yes". And then the conneciton check again.

Can someone explain what is happening here? It looks like the YUI REST API is suddenly dead and this death affects even our logging in openQA.

I moved the yast2_restart_bond test a bit up in the YAML schedule and now I got 3 runs in a row without problems:
https://openqa.suse.de/tests/16130097#next_previous

Created PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20763