Custom ordering for replicasets #882
Labels
good first issue
Denotes an issue ready for a new contributor, according to the "help wanted" guidelines.
help wanted
Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
priority/awaiting-more-evidence
Lowest priority. Possibly useful, but not yet enough support to actually get it done.
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.
The text was updated successfully, but these errors were encountered: