Capturing internal email and in-person discussions.

The choice of which pod to kill when a replication controller replica count is decreased (or the replication controller otherwise detects that it somehow has too many pods) could become fairly nuanced, and even application-specific (e.g., don't kill the current master in a master-elected service). One way in which we could make the policy extensible is to generate an event that indicates pods need to be killed and then wait some amount of time. That would provide an opportunity for a user-provider pod killer to make the choice.

That's not to say that we shouldn't make the default choice more intelligent over time (e.g., taking into account application readiness), but the default policy will never satisfy everyone.

Events when pods are actually killed and created would be useful, too.