Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
verification steps in:
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 ))
echo "apiVersion: certificates.k8s.io/v1beta1
request: $(cat server.csr | base64 | tr -d '\n')
- digital signature
- key encipherment
- server auth" > wow$c &&echo $c&&kubectl create -f wow$c&
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
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)
*** Bug 1901918 has been marked as a duplicate of this bug. ***
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.
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.