While in openshift-kube-apiserver revision-pruner seems to happen, it seems that in oauth-apiserver namespace similar pruning/cleanup functionality is missing, causing number of ConfigMaps to pile up. It's also not clear whether those ConfigMap revisions are still required or could be removed as it would reduce amount of objects required to be managed by the platform.

> $ oc get cm -A | grep revision-status | cut -d ' ' -f1 | sort -h | uniq -c | sort -h
>       5 openshift-etcd
>       5 openshift-kube-apiserver
>       5 openshift-kube-controller-manager
>       6 openshift-kube-scheduler
>       8 openshift-oauth-apiserver
>      23 openshift-apiserver

> $ oc get cm -A | grep audit | cut -d ' ' -f1 | sort -h | uniq -c | sort -h
>       1 openshift-monitoring
>       6 openshift-kube-apiserver
>       9 openshift-oauth-apiserver
>      24 openshift-apiserver

The above output is from a OpenShift Container Platform 4 - Cluster that has been running for 5 days. Looking at the numbers of ConfigMaps now, just consider the number shown when the OpenShift Container Platform 4 - Cluster would run for 1 or 2 year. It would host a massive amount of ConfigMaps which are likely not required but will need to be managed by the platform and potentially required to be re-encrypted every 7 days (which seems unnecessary).

OpenShift Container Platform 4.10

Always

1. Install OpenShift Container Platform 4
2. Trigger some revision
3. Check ConfigMaps as shown above and verify that they are not pruned in some namespaces

No pruning/cleanup of oauth-apiserver revision ConfigMaps are happening and it first of all cerates a unecessary list of ConfigMaps required to be managed and it's also not clear whether those are still required or not.

Some pruning functionaliry would be desired if and where possible to keep number of objects created and managed under control