Change:
svc.Spec.LoadBalancerSourceRanges = []string{acceptPod.Status.PodIP + "/32"} }) <del> // Clean up loadbalancer service </del> defer func() { <del> jig.UpdateServiceOrFail(svc.Namespace, svc.Name, func(svc *v1.Service) { svc.Spec.Type = v1.ServiceTypeNodePort svc.Spec.LoadBalancerSourceRanges = nil }) err := cs.CoreV1().Services(svc.Namespace).Delete(svc.Name, nil) framework.ExpectNoError(err) </del> <ins> ginkgo.By("Clean up loadbalancer service") e2eservice.WaitForServiceDeletedWithFinalizer(cs, svc.Namespace, svc.Name) </ins> }() svc = jig.WaitForLoadBalancerOrFail(namespace, serviceName, loadBalancerCreateTimeout)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gce-scale-correctness Which test(s) are failing: [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] Since when has it been failing: It has been failing since 8/28. Here is the k/k diff for additional context: Testgrid link: Reason for failure: Seems like they were two instances of the same test (at least in the latest run). One of them failed with the following error message: The other one with: /milestone v1.16 /priority critical-urgent /kind failing-test /cc /cc /cc
/sig network
- are you aware of any recent changes that might affect this tests (e.g. judging just by title)? It fails deterministically.
/remove-kind bug Actually
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Those labels are not set on the issue: <detailsIn response to : /remove-kind node /assign - any chance this is related to ? This is a little wild guess, but from logs it seems that the namespace wasn't deleted, because objects other that pods were not deleted () Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Those labels are not set on the issue: <detailsIn response to : /remove-sig node Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Those labels are not set on the issue: <detailsIn response to : /remove-kind node /assign - any chance this is related to ? This is a little wild guess, but from logs it seems that the namespace wasn't deleted, because objects other that pods were not deleted () Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign Any chance this is related to ?

This is a little wild guess, but from logs it seems that the namespace wasn't deleted, because objects other that pods were not deleted ()
can you please let the 1.16 release team if you are going to be able to investigate and provide if you can help an approximate time for a fix?
Acked, I'm looking into the failure and will provide an update soon.
Fantastic! Thanks for the update
Yep, this is related to With service finalizer enabled by default, deleting the namespace (including services) now takes longer --- it now blocks on all the underlying load balancer resources to be cleaned up. It is expected that the latency for resource clean up might be longer on large cluster (such as in this test). I will soon send a PR to overwrite the  with something more reasonable in this case.
Sent to fix this.
Reopening this one to track the job's health /reopen
Reopened this issue. <detailsIn response to : Reopening this one to track the job's health /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Yesterday's run has failed due to problems with creating a test cluster. Hopefully we get an answer whether the fix has helped today.
Thanks for tracking this, seems like the latest run is green:
It looks good indeed, thanks /close
Closing this issue. <detailsIn response to : It looks good indeed, thanks </details