action #46232: [functional][y] test fails in yast2_hostnames - too tight grep pattern? - openQA Tests - openSUSE Project Management Tool

Actions

Copy link

action #46232

closed

[functional][y] test fails in yast2_hostnames - too tight grep pattern?

Added by dimstar over 5 years ago. Updated about 5 years ago.

Status:

Resolved

Priority:

High

Assignee:

oorlov

Category:

Bugs in existing tests

Target version:

SUSE QA - Milestone 22

Start date:

2019-01-15

Due date:

2019-01-29

% Done:

Estimated time:

3.00 h

Difficulty:

Description

Observation¶

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-yast2_gui@64bit fails in
yast2_hostnames

Reproducible¶

Fails since (at least) Build 20190112

Expected result¶

Last good: 20190110 (or more recent)

Further details¶

Always latest result in this scenario: latest

without having checked (yet) the written /etc/hosts, I somewhat expect the grep pattern to be too tight in this test: already having multiple spaces between the entries (which would be perfectly valid) would make the test fail

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by okurz over 5 years ago

Subject changed from test fails in yast2_hostnames to [functional][y] test fails in yast2_hostnames - too tight grep pattern?
Due date set to 2019-01-29
Priority changed from Normal to High
Target version set to Milestone 22

Hi @dimstar you might have better chances at having issues like these fixed faster when you add the according team tags, e.g. for everything that looks like "clearly yast" use "[functional][y]" in the subject line. Also please provide a little hint in the subject line because the subject line should be catchy for people to motivate ;)

Also, for issues linked to current tests failing I tend to pick the priority of at least "High" so feel free to do so as well.

Actions

Copy link

Updated by riafarov over 5 years ago

That's the regression introduced by agraul's PR.

Actions

Copy link

Updated by riafarov over 5 years ago

Status changed from New to Workable
Estimated time set to 3.00 h

Actions

Copy link

Updated by oorlov over 5 years ago

Assignee set to oorlov

Actions

Copy link

Updated by oorlov over 5 years ago

Status changed from Workable to In Progress

Actions

Copy link

Updated by oorlov over 5 years ago

The issue caused by https://bugzilla.opensuse.org/show_bug.cgi?id=1122387

Error occurred while saving edited host configuration and changes are not applied. So, the grep is failed, because there is no changed line in /etc/hosts/.

Actions

Copy link

Updated by dimstar over 5 years ago

Thanks - might it be an option for the test to upload /etc/hosts as well when it fails? This would make it a lot easier to debug things like this

Actions

Copy link

Updated by oorlov over 5 years ago

Yes, good idea. I will implement this.

Actions

Copy link

Updated by oorlov over 5 years ago

Status changed from In Progress to Feedback

To simplify issues investigation for the yast2_hostname module, the /etc/hosts file is uploaded on post fail hook;
The grep pattern is changed to allow multiple spaces between the entries in /etc/hosts file.

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

Actions

Copy link

#10

Updated by oorlov about 5 years ago

Status changed from Feedback to In Progress

I also planned to fail the test if 'YaST2 - Hostnames' dialog is not closed (on error appearing) instead of executing further steps. But I've faced a problem, that while switching to 'log-console', the 'root-console' appears for a while (e.g. test step) and then it actually switches to 'log-console'.

Example: http://oorlov-vm.qa.suse.de/tests/738

I'm in progress of figuring out how to solve the issue.

Actions

Copy link

#11

Updated by okurz about 5 years ago

[23/01/2019 11:46:01] <okurz> oorlov: that's interesting. I mean, I understand why it matches the needle and *thinks* it's on log console but it's on root-console. However, why does it even *show* the root console when we came from x11?
[23/01/2019 11:47:33] <oorlov> okurz, this is the question:) It seems like UI issue. I also started the test in openQA and connected to the vnc and observed this behavior. It shows root-console for a second and then switches to the required one
[23/01/2019 11:48:16] <okurz> what do you mean with "UI issue"? I guess it's more like how the kernel behaves when switching from x11 to *any* tty, that it can show the previous tty for short.
[23/01/2019 11:49:32] <oorlov> okurz, yes, kernel maybe. I just wanted to state, that it is issue of the product. You know, namings are not my strongest part:)
[23/01/2019 11:49:52] <okurz> ah, true.
[23/01/2019 11:50:22] <okurz> oorlov: Well, I have an idea though. We can change the code to just look for the "text-logged-in-root" in case of loading qemu snapshots. This is related to aa9593aed as I see it.

I suggest to only check for "text-logged-in-root" when we load from snapshots. However I am not sure if we only need this when "SKIPTO" is specified, e.g. in local debugging sessions, or also when we revert to snapshots in case of errors. I suggest to test three cases:

Single module uses root-console, fails, switches to root-console -> assert that executes post_fail_hook correctly on post_fail_hook
Multiple modules on qemu backend, one module fails, next module loads previous qemu snapshot -> assert that module succeeding to failing one execute correctly
In local instance with MAKETESTSNAPSHOTS=1 and SKIPTO=… specified -> assert that the module specified with SKIPTO can access the still logged in root console

Actions

Copy link

#12