Description
Copying from a comment in issue 817, #817 (comment)
I think replica sets need custom ordering, because of the way they are created and managed by deployments.
To give you an example, assume that I have three deployments, A, B and C, that I learned the lesson and that I set revisionHistoryLimit to 3. This means I'll eventually have four replica sets for each (current rollout, plus history of three).
The rollouts happen with different schedules. For convenience, let's refer to the replica sets with {DEPLOYMENT}{AGE_IN_DAYS}. So I have A0, A7, A14, A21, B9, B19, B29, B39, C1, C3, C5, C7.
The only ones to have any running pods are A0, B9, C1, unless there's a rolling update in progress. So the best ordering might be those three (sorted by date, preferably, so that during an update the 'fresh' replica set shows first, or otherwise name), followed by all the other empty replica sets. If I merely sorted by age, I would have useless replicasets like C3, C5, C7 and A7 showing up before B9. Even worse if I sorted by name. The inconvenience only gets worse when the number of deployments or the history size are large (I have 10 for the latter). Or when users don't set any history limits at all.
I would make the case that the empty replica sets should actually be ghosted, show fewer details and/or be hidden by default. Also, like Borg, it would be nice to highlight a RS or RC that is undergoing updates.