Project

General

Profile

Actions

action #46232

closed

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

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

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 22
Start date:
2019-01-15
Due date:
2019-01-29
% Done:

0%

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 open1 closed)

Related to openQA Tests - action #48074: [functional][y] test fails in yast2_hostnamesResolvedoorlov2019-02-182019-03-12

Actions
Actions #1

Updated by okurz about 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 #2

Updated by riafarov about 5 years ago

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

Actions #3

Updated by riafarov about 5 years ago

  • Status changed from New to Workable
  • Estimated time set to 3.00 h
Actions #4

Updated by oorlov about 5 years ago

  • Assignee set to oorlov
Actions #5

Updated by oorlov about 5 years ago

  • Status changed from Workable to In Progress
Actions #6

Updated by oorlov about 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 #7

Updated by dimstar about 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 #8

Updated by oorlov about 5 years ago

Yes, good idea. I will implement this.

Actions #9

Updated by oorlov about 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 #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 #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 #12

Updated by oorlov about 5 years ago

  • Status changed from In Progress to Feedback
Actions #13

Updated by oorlov about 5 years ago

I've restarted the job: https://openqa.suse.de/tests/2404543

Actions #14

Updated by oorlov about 5 years ago

  • Status changed from Feedback to Resolved

Verified. Resolved.

Actions #15

Updated by okurz about 5 years ago

  • Related to action #48074: [functional][y] test fails in yast2_hostnames added
Actions

Also available in: Atom PDF