action #52664
closed[functional][y] test times out as incomplete in await_install failing to download packages from download.o.o, should fail module and run post_fail_hook instead
0%
Description
Observation¶
openQA test in scenario opensuse-5.12.80-Krypton-Live-x86_64-krypton-live-installation@64bit-2G fails in
await_install
Test suite description¶
Boots the openSUSE Krypton/Argon Live DVD and uses the installer to install with default settings, then reboots into the installed system.
Reproducible¶
Fails since (at least) Build 8.122 (current job)
Expected result¶
Last good: 8.120 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by riafarov over 5 years ago
- Status changed from New to Resolved
- Assignee set to riafarov
Issues is resolved by creating proper needle with yast_error
tag.
Updated by okurz over 5 years ago
- Status changed from Resolved to Feedback
ok but I guess there is another problem that the sum of the internal timeouts exceed MAX_JOB_TIME. How about simply scaling MAX_JOB_TIME accordingly?
Updated by riafarov over 5 years ago
- Assignee changed from riafarov to okurz
- Target version set to future
okurz wrote:
ok but I guess there is another problem that the sum of the internal timeouts exceed MAX_JOB_TIME. How about simply scaling MAX_JOB_TIME accordingly?
I believe that more than 2 hours is too much to be handled as "normal", so we should handle it case by case.
In case you disagree, please, scale the settings for all the test suites, as this problem might appear for any scenario, good luck ;)
Updated by okurz over 5 years ago
- Assignee changed from okurz to riafarov
the problem is that the sum of the internal timeout is already higher than 2h so bumping the timeout of the complete scenario is just one option, reducing internal timeouts, e.g. in await_install is another one. As "await_install" falls in the domain of QSF-y I think this should be something for your team. This should even help you because it would make review easier when jobs fail in await_install instead of incompleting without proper issue carry over. When you think that you in your team are fine with the incompletes then you can just reject the ticket (or set back to Resolved)
Updated by riafarov over 5 years ago
- Status changed from Feedback to Resolved
We are not fine with incompletes, but we are not going to fix potential problems which might occur. I've fixed the issue you've reported, thanks for that, so now this case is covered. Once we see another one, we act accordingly. Cheers ;)