Project

General

Profile

action #121567

test fails in test_running

Added by tinita about 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Concrete Bugs
Target version:
Start date:
2022-12-06
Due date:
2022-12-21
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
test_running

Test suite description

Maintainer: okurz@suse.de Test for installation of openQA itself. To be used with "openqa" distri. Publishes an qcow2 image including the openQA installation ready to run as an appliance.

Reproducible

Fails since (at least) Build :TW.12917 (current job)

Expected result

Last good: :TW.12916 (or more recent)

Further details

Always latest result in this scenario: latest

Looking at the video and in the log retry doesn't seem to do any retries:

[2022-12-06T12:02:51.501219+01:00] [debug] <<< testapi::assert_script_run(cmd="retry -s 30 -r 5 -- openqa-cli api jobs state=running state=done | ack --passthru --color \"running|done\"", fail_message="", timeout=300, quiet=undef)
...
[2022-12-06T12:02:58.353973+01:00] [info] ::: basetest::runtest: # Test died: command 'retry [...]

That's only 7 seconds.
I guess that's because the openqa-cli command passes, and the ack fails, but the retry is attached to the openqa-cli command.

Possibly related: https://github.com/os-autoinst/openQA/pull/4935 Avoid running jobs with undetermined worker address


Related issues

Related to openQA Infrastructure - action #120261: tests should try to access worker by WORKER_HOSTNAME FQDN but sometimes get 'worker2' or something auto_review:".*curl.*worker\d+:.*failed at.*":retry size:meowResolved2022-11-10

History

#1 Updated by tinita about 2 months ago

  • Description updated (diff)

#2 Updated by okurz about 2 months ago

  • Related to action #120261: tests should try to access worker by WORKER_HOSTNAME FQDN but sometimes get 'worker2' or something auto_review:".*curl.*worker\d+:.*failed at.*":retry size:meow added

#3 Updated by okurz about 2 months ago

https://openqa.opensuse.org/tests/2931073#step/test_running/11 states

[warn] Unable to determine worker address (WORKER_HOSTNAME) - checking again for web UI 'localhost' in 20.00 s

#4 Updated by tinita about 2 months ago

  • Description updated (diff)

#5 Updated by mkittler about 2 months ago

Looks like the worker cannot determine WORKER_HOSTNAME in this test environment. That it then refuses to run jobs (until the problem is fixed) is actually a feature and not a bug. I suppose we can simply set WORKER_HOSTNAME here explicitly (e.g. even to 127.0.0.1 to make it clear that this worker isn't meant to be reached from the outside).

#6 Updated by mkittler about 2 months ago

  • Assignee set to mkittler

#8 Updated by openqa_review about 2 months ago

  • Due date set to 2022-12-21

Setting due date based on mean cycle time of SUSE QE Tools

#9 Updated by mkittler about 2 months ago

  • Status changed from In Progress to Feedback

I ended up creating a 3rd PR (and closing the other ones): https://github.com/os-autoinst/openQA/pull/4949

It has been merged. Let's see whether that fixes the openQA-in-openQA test.

#10 Updated by okurz about 2 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF