Bug 1843923 - After the start the upload of results shouldn't be delayed - release 4.3
Summary: After the start the upload of results shouldn't be delayed - release 4.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Insights Operator
Version: 4.5
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: 4.3.z
Assignee: Martin Kunc
QA Contact: Pavel Šimovec
Radek Vokál
URL:
Whiteboard:
: 1841059 (view as bug list)
Depends On: 1842489
Blocks: 1841064 1843924
TreeView+ depends on / blocked
 
Reported: 2020-06-04 12:20 UTC by OpenShift BugZilla Robot
Modified: 2020-09-23 13:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The Insights Operator is only uploading data after first polling interval, (2h+-15m). Consequence: The data collected by Insights Op. are then not available instantly. The Insishgts data available in OCM are then delayed. Fix: This fix is changing uploading logic to upload the data as soon as they are collected for the first time. The logic for consequent uploads isn't changing. Result:
Clone Of:
Environment:
Last Closed: 2020-09-23 13:52:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift insights-operator pull 137 0 None closed [release-4.3] Bug 1843923: Don't delay first 2020-09-29 04:04:17 UTC
Red Hat Product Errata RHBA-2020:3609 0 None None None 2020-09-23 13:53:02 UTC

Comment 1 Martin Kunc 2020-06-04 12:24:50 UTC 
*** Bug 1841059 has been marked as a duplicate of this bug. ***
Comment 2 Martin Kunc 2020-08-10 04:06:05 UTC 
The faster data collection will be important for CEE organization ("support"), increasing priority to High.
Comment 6 Pavel Šimovec 2020-09-16 11:52:06 UTC 
Version 4.3.0-0.nightly-2020-09-12-071205
I used test/integration/bugs_test.go::TestUploadNotDelayedAfterStart

First try: could not verify -> Fast upload was not enabled, because "The last pod state is unhealthy".. so the upload took ~40 minutes, with the unhealthy pod given it worked as expected
I discused this with Martin and he found the cause of failure - a new Jira task will be created for that problem

Second try: provisioned cluster again, this time I did get healthy pod and test passed with message: "Archive upload delay was 37 seconds" -> this BZ is verified
Comment 8 errata-xmlrpc 2020-09-23 13:52:39 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.3.38 bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3609
Note You need to log in before you can comment on or make changes to this bug.