Project

General

Profile

Actions
Copy link

action #122659

closed

QA - coordination #121720: [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuring availability

QA - coordination #116623: [epic] Migration of SUSE Nbg based openQA+QA+QAM systems to new security zones

coordination #122650: [epic] Fix firewall block and improve error reporting when test fails in curl log upload

Improved error reporting in openQA tests when curl times out on connection attempts

Added by okurz over 1 year ago. Updated 5 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
okurz
Category:
Feature requests
Target version:
Ready
Start date:
2023-01-03
Due date:
% Done:

0%

Estimated time:

Description

Motivation

See parent #122650. The problem as reported in #122539 is that openQA tests fail with just a "timeout" trying to execute curl and no clear error indication. As it looks like default connect timeout for curl resolves to 2m10s (see above) so that is above our default timeouts for script_run or upload_logs from the openQA test API. So find a combination where curl has a chance to provide a proper error earlier.

Acceptance criteria

  • AC1: openQA tests failing due to curl connection timeouts provide better feedback than in #122539

Suggestions

  • Consider using upload_logs in this specific example but this does not completely help. upload_logs uses a default timeout of 90s which is higher than the default for script_run of 30s which is still below the default for curl accounting to 2m10s. Theoretically we could add the parameter --connect-timeout 20 to curl but then this needs to be always typed even over slow VNC connections and is error prone. Or we bump the timeout for upload_logs and ensure that people actually use upload_logs and not script_run manually.
Actions
Copy link
 #1

Updated by okurz over 1 year ago

  • Target version changed from Ready to future
Actions
Copy link
 #2

Updated by okurz 5 months ago

  • Status changed from New to Rejected
  • Assignee set to okurz
  • Target version changed from future to Ready

With NUE1 decommissioned all active systems are in new security zones and I guess machines that are brought (back) into production will also end up in new security zones. No specific work for improving error reporting here was done and I don't think we need to improve that further. We need to rely on SUSE-IT to monitor their firewall accordingly.

Actions
Copy link

Also available in: Atom PDF