Description of problem: We should never have too many revisions. Add an e2e test to confirm revisions are being pruned. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We need this to prevent future hotloops like we saw in the kube-scheduler-operator
Do we want to set a limit to the prune controller too that keeps the maximum revisions at <=20 along with the test? Right now the the Succeeded/Failed revision limits could be set higher than that with no problem, with I think 0 or -1 actually being unlimited revisions. Is there more info on what this is for?
@Mike, I my mention of pruning was incorrect/irrelevant in my original description. This is more about a fresh cluster who, already has over 20 revisions right after install, strongly suggesting that there is some hotlooping going on.
Ah, that is interesting considering that by default we set the limit at 5/5 succeed/fail revisions. It seems to me like occasionally older revisions may get stuck in the "InProgress" state (eg, I have a cluster right now with 9 revisions, but somehow #4 never updated past InProgress). We don't count InProgress revisions toward any limit, so there might also be some work here to take those into consideration or refine our logic for determining success/fail.
PR https://github.com/openshift/cluster-kube-apiserver-operator/pull/441
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, 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-2019:2922