Change:
t.Errorf("Expected 1 call but got 0") } } <ins> func TestSortingActivePods(t *testing.T) { numPods := 5 podList := newPodList(numPods) pods := make([]*api.Pod, len(podList.Items)) for i := range podList.Items { pods[i] = &podList.Items[i] } // pods[0] is not scheduled yet. pods[0].Spec.Host = "" pods[0].Status.Phase = api.PodPending // pods[1] is scheduled but pending. pods[1].Spec.Host = "bar" pods[1].Status.Phase = api.PodPending // pods[2] is unknown. pods[2].Spec.Host = "foo" pods[2].Status.Phase = api.PodUnknown // pods[3] is running but not ready. pods[3].Spec.Host = "foo" pods[3].Status.Phase = api.PodRunning // pods[4] is running and ready. pods[4].Spec.Host = "foo" pods[4].Status.Phase = api.PodRunning pods[4].Status.Conditions = []api.PodCondition{{Type: api.PodReady, Status: api.ConditionTrue}} getOrder := func(pods []*api.Pod) []string { names := make([]string, len(pods)) for i := range pods { names[i] = pods[i].Name } return names } expected := getOrder(pods) for i := 0; i < 20; i++ { idx := rand.Perm(numPods) randomizedPods := make([]*api.Pod, numPods) for j := 0; j < numPods; j++ { randomizedPods[j] = pods[idx[j]] } sort.Sort(activePods(randomizedPods)) actual := getOrder(randomizedPods) if !reflect.DeepEqual(actual, expected) { t.Errorf("expected %v, got %v", expected, actual) } } } </ins>

Discussion:
I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil