Bug 1893766 - IO archive contains more records of than is the limit
Summary: IO archive contains more records of than is the limit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Insights Operator
Version: 4.7
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.7.0
Assignee: Ricardo Lüders
QA Contact: Pavel Šimovec
URL:
Whiteboard:
Depends On:
Blocks: 1894244
TreeView+ depends on / blocked
 
Reported: 2020-11-02 14:45 UTC by Ricardo Lüders
Modified: 2020-11-27 10:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1901918 (view as bug list)
Environment:
Last Closed: 2020-11-26 12:50:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift insights-operator pull 246 0 None closed Bug 1893766: IO archive contains more records of than is the limit 2021-02-11 09:31:59 UTC

Description Ricardo Lüders 2020-11-02 14:45:10 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Pavel Šimovec 2020-11-06 10:07:09 UTC
verification steps in:
https://bugzilla.redhat.com/show_bug.cgi?id=1881044

Comment 3 Pavel Šimovec 2020-11-06 11:56:02 UTC
I have repeated verification steps from https://bugzilla.redhat.com/show_bug.cgi?id=1881044 :
I have run this script to create 5000+ csr
for (( c=18500; c<=50300; c=c+1 ))
do
echo "apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: service$c.default
spec:
  groups:
  - system:authenticated
  request: $(cat server.csr | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth" > wow$c &&echo $c&&kubectl create -f wow$c&
sleep 0.17;
done

During that time I have run e2e-test TestArchiveContains::csr
main_test.go:362: 5197 csr files match pattern `^config/certificatesigningrequests/.*\.json$`

There are more csr files than 5000, which is supposed to be the limit.

VERIFICATION FAILED - the change in the PR might be OK, but the problem PERSISTS

After stopping the script that creates csrs, and running the tests again the count of csrs stabilized at 5000, as expected

oc get clusterversion
NAME      VERSION                        AVAILABLE   PROGRESSING   SINCE     STATUS
version   4.7.0-0.ci-2020-11-03-102229   True        False         58m       Cluster version is 4.7.0-0.ci-2020-11-03-102229


(following text is just some basic description of possibly a different problem, I need to investigate it more..
When I was adding more and more csrs, my tests started to fail - after restarting 
Possibly found another problem, possibly the problem is in my tests... 

inside IO pod, /var/lib/insights-operator..
> tar tf insights-2020-11-06-112043.tar.gz
...
config/certificatesigningrequests/aservice18795.default.json
config/certificatesigningrequests/aservice18796.default.json
config/certificatesigningrequests/aservice18797.default.json
config/certificatesigningrequests/aservice18798.default.json
config/certificatesigningrequests/aservice18799.default.json
config/certificatesigningrequests/aservice18800.default.json
config/certificatesigningrequests/aservice18801.default.json
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Probably it was trying to untar the archive when it wasn't ready yet)

Comment 4 Ricardo Lüders 2020-11-26 12:46:05 UTC
*** Bug 1901918 has been marked as a duplicate of this bug. ***

Comment 5 Ricardo Lüders 2020-11-26 12:50:39 UTC
This is just a reminder that we found an issue with the limit of the reports at the IO, but at the same time, after several tests, nobody seems to be able to reproduce it.
We spend a lot of time and effort investigating this one and without any positive result. After discussing it, we decide that we won't fix it, 'cause if it is happening, it probably an exception or a relly specific case, that doesn't seem easy to find out or even to reproduce.

Comment 6 Ricardo Lüders 2020-11-27 10:17:59 UTC
This BZ is just related to the PR that implement some limit to the IO, there is another one (1901918) that describes the issue that we won't fix.


Note You need to log in before you can comment on or make changes to this bug.