action #46232
closed
[functional][y] test fails in yast2_hostnames - too tight grep pattern?
Added by dimstar over 5 years ago.
Updated over 5 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 22
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
- 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.
That's the regression introduced by agraul's PR.
- Status changed from New to Workable
- Estimated time set to 3.00 h
- Status changed from Workable to In Progress
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
Yes, good idea. I will implement this.
- Status changed from In Progress to Feedback
- 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.
[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
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
- Related to action #48074: [functional][y] test fails in yast2_hostnames added
Also available in: Atom
PDF