Description of problem:
Latest implementation of history pruner (pr805 ) had increased max upgrade history in cvo to 100, and implemented a weight based pruning priority strategy for in case history length grows any larger. This pruning however is not happening, letting history grow uncontrollably, and potentially reach resource limits of etcd or kubernetes.
Observed the following while running continuous upgrade-rollback cycles:
$ oc get clusterversion version -o json | jq '.status.history|length'
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Same as described in bz2097067 , with addition of waiting a few minutes after the first rollback to allow it to reach 'Completed' state.
History grows uncontrollably
History should be pruned to keep max size of 100