Bug 1191556 - yast inst_overview race condition?
yast inst_overview race condition?
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://openqa.opensuse.org/tests/196...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-12 07:13 UTC by Ludwig Nussel
Modified: 2021-11-02 16:08 UTC (History)
2 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2021-10-12 07:13:27 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-NET-x86_64-textmode+selinux@uefi fails in
[start_install](https://openqa.opensuse.org/tests/1961554/modules/start_install/steps/3)

In the inst_overview screen the test selects the security module to enable SELinux:
https://openqa.opensuse.org/tests/1961554#step/enable_selinux/2

After it hit "OK" to enable selinux the test verifies that it sees the inst_overview screen complete again:
https://openqa.opensuse.org/tests/1961554#step/enable_selinux/6

Now suddenly yast seems to notice it needs to redo the proposal:
https://openqa.opensuse.org/tests/1961554#step/enable_selinux/7

That of course breaks the workflow as openqa already thought it's at a working inst_overview screen and can press the install button.

There are some test in the history that pass so looks like a very quick flash of the screen that openQA sometimes doesn't even recognize. It only happens in text mode. The graphical tests work very reliable.

Is there a way to avoid this behavior of the ncurses interface, ie not show a screen that has to be redone just the blink of an eye later?
Comment 1 Stefan Hundhammer 2021-10-14 15:13:03 UTC
I am pretty sure this is not unique to NCurses, it's just regular event ping-pong. It might just be a bit slower in this case than usual.

IIRC QA has a workaround for those situations with simply waiting for half a second or so until everything settles.
Comment 2 Ludwig Nussel 2021-10-18 08:04:42 UTC
there's actually a two second sleep in there:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/ecc5c6f7b0d173f7141c084e32644973f3017e54/tests/installation/start_install.pm#L86

We can see in the logs that it works (enter test at second 53 and send key at 55):

[2021-10-10T12:57:53.388042+02:00] [debug] ||| starting start_install tests/installation/start_install.pm
[2021-10-10T12:57:55.388998+02:00] [debug] tests/installation/start_install.pm:87 called testapi::send_key
[2021-10-10T12:57:55.389230+02:00] [debug] <<< testapi::send_key(key="alt-i", wait_screen_change=0, do_wait=0)


AFAICS the code basically enters this ask_user function that opens and closes a dialog itself. So I suppose the UI gets redrawn when ask_user closes it's dialog and before returning. However only after returning from ask_user the calling code can decide whether it needs to recalculate the proposal.
Maybe the issue could be worked around by blanking the proposal screen right before entering ask_user. When the call comes back the code can then decide whether to put back the previous content (if no change needed) or the "recalculating .." text.
Comment 3 Stefan Hundhammer 2021-11-02 14:12:16 UTC
I don't know what's going on there.

This might be a case of that SELinux proposal doing something wrong; it's relatively new.

Or it might simply be very slow with one of the actions that it performs when recreating its proposal, so the timeout on the OpenQA side isn't long enough.

AFAICs somebody will have to dig deep into debugging this.
Comment 4 José Iván López González 2021-11-02 16:07:42 UTC
Ok, I will create a trello card to debug what is taking longer there. Then we can decide the solution (increasing timeout or fixing something).