Project

General

Profile

Actions

action #121567

closed

test fails in test_running

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

Status:
Resolved
Priority:
High
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2022-12-06
Due date:
2022-12-21
% Done:

0%

Estimated time:

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 1 (0 open1 closed)

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:meowResolvedmkittler2022-11-10

Actions
Actions #1

Updated by tinita over 1 year ago

  • Description updated (diff)
Actions #2

Updated by okurz over 1 year 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
Actions #3

Updated by okurz over 1 year 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
Actions #4

Updated by tinita over 1 year ago

  • Description updated (diff)
Actions #5

Updated by mkittler over 1 year 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).

Actions #6

Updated by mkittler over 1 year ago

  • Assignee set to mkittler
Actions #8

Updated by openqa_review over 1 year ago

  • Due date set to 2022-12-21

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

Actions #9

Updated by mkittler over 1 year 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.

Actions #10

Updated by okurz over 1 year ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF