Project

General

Profile

Actions

action #115313

closed

test fails in firewalld_policy_objects

Added by RBrownSUSE over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2022-08-15
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-firewalld-policy-client@64bit fails in
firewalld_policy_objects

SUT reports "Nexthop has invalid gateway", and as the snaphot includes no major networking changes the implication is that the test is doing something invalid which is only now being picked up.

Test suite description

Maintainer: mgrifalconi - qe-core

Reproducible

Fails since (at least) Build 20220814

Expected result

Last good: 20220813 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by okurz over 1 year ago

The last good is from Sunday morning https://openqa.opensuse.org/tests/2514184. I see the same consistent error report on openqaworker1,4,7. One has to be careful evaluating https://openqa.opensuse.org/tests/2515701#next_previous as it seems there are (at least) two different failures in the module firewalld_policy_objects.

Based on the investigation results in https://openqa.opensuse.org/tests/2515385#comments, the first bad of today to me it looks like it's actually a product regression in build 20220814.

Actions #2

Updated by favogt over 1 year ago

  • Status changed from New to In Progress

With https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15371 it reliably gets further again and passes if nothing else breaks. I guess it's a product behaviour change but one that is acceptable (or even expected?) and just needs to be dealt with.

Actions #3

Updated by favogt over 1 year ago

  • Assignee set to favogt

Let's also use this ticket for this different failure: https://openqa.opensuse.org/tests/2517143

What happened there is that the mysite.conf asset download actually received a 404 page, resulting in a syntax error. The reason for that is (I believe) that the request to 10.0.2.2 is routed through the "-firewall" SUT, which is on a different worker in this case. That doesn't know anything about the job token of the "-client" (or "-server") SUTs and thus returns the 404 page. In the end, this looks to me like a "how could this ever have worked?" scenario. Am I missing something?

If not, https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15372 should address that as well.

Actions #4

Updated by favogt over 1 year ago

  • Status changed from In Progress to Resolved

Both PRs merged, let's see whether this test is now reliable.

Actions

Also available in: Atom PDF