Change:
t.Helper() assert.ElementsMatch(t, expected, r.evaluations) } <ins> func TestPrioritizePods(t *testing.T) { isController := true sampleOwnerReferences := []struct { ownerRefs []metav1.OwnerReference }{ { ownerRefs: []metav1.OwnerReference{ { UID:        uuid.NewUUID(), Controller: &isController, }, }, }, { ownerRefs: []metav1.OwnerReference{ { UID:        uuid.NewUUID(), Controller: &isController, }, }, }, { ownerRefs: []metav1.OwnerReference{ { UID:        uuid.NewUUID(), Controller: &isController, }, }, }, } var pods []*corev1.Pod randomSource := rand.NewSource(time.Now().Unix()) for _, sampleOwnerRef := range sampleOwnerReferences { // Generate multiple pods for a controller for i := 0; i < rand.New(randomSource).Intn(5)+len(sampleOwnerReferences); i++ { pods = append(pods, &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ OwnerReferences: sampleOwnerRef.ownerRefs, }, Spec: corev1.PodSpec{}, }) } } a := &Admission{} prioritizedPods := a.prioritizePods(pods) controllerRef := make(map[types.UID]bool) for i := 0; i < len(sampleOwnerReferences); i++ { if controllerRef[metav1.GetControllerOfNoCopy(prioritizedPods[i]).UID] { assert.Fail(t, "Pods are not prioritized based on uniqueness of the controller") } controllerRef[metav1.GetControllerOfNoCopy(prioritizedPods[i]).UID] = true } if len(prioritizedPods) != len(pods) { assert.Fail(t, "Pod count is not the same after prioritization") } } </ins>

Discussion:
When updating policy labels on a namespace, existing pods are evaluated to see if they are compatible with the new policy. If there are too many pods, or if evaluation takes too long, we short circuit and warn that not all pods were checked. For that reason, we want to prioritize checking a variety of pods before checking essentially identical pods, so that unique warnings can be surfaced before reaching the pod count cutoff or evaluation timeout. Pods created by the same controller are most likely to be identical (e.g. replicas from a replicaset or job, copies of pods from a statefulset or daemonset, etc) cc
This is an interesting fix I'd like to take this up Can I take this up? I am fairly new to Kubernetes source code so might need some help
I am guessing this is where the logic you mentioned should be implemented right?
thanks for the interest; this is targeted at the beta version... right now, effort is going toward the alpha-blocking work for 1.22
Should I wait for the code freeze before working on this? Sorry for lame questions
If you want to start looking at it, that's fine, but it's possible the code in the ValidateNamespace function will change before we're ready to start merging 1.23 work, and there isn't really reviewer bandwidth to take a look at work-in-progress stuff for next release yet.
Sure, I'll just for code freeze before I start with implementation By the time I'll just assign this to myself /assign
Does it make sense to take it up now? I think we already have a couple of RC builds after the code freeze
sure, it's fine to start work in a branch in your fork and have a WIP PR open, even before master reopens for 1.23 work
Awesome, I'll start working on it Thank you
Hello! Are you still working on this? If you don't have time, I can take this issue. If not, maybe I can give some help
Since this was not an urgent issue I was working on some other issues last week I have started on this, Will be raising a PR maybe today or tomorrow I Will ask you if I get stuck Thank you