Change:
master-informing gce-master-scale-correctnessKubernetes e2e suite.[It] [sig-network] Services GCE [Slow] should be able to create and tear down a standard-tier load balancer [Slow] ! 2023-05-24 10:01 PDT Kubernetes e2e suite: [It] [sig-network] Services GCE [Slow] should be able to create and tear down a standard-tier load balancer [Slow] No response /sig scalability cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
/sig network
Ok, checking job Download controller-manager logs There are these errors already reported in but that doesn't seem the problem This is weird does this ring a bell? ^^
It seems to be a flake which is passed in the last run.
Yes, I see the last run Green; so closing this as of now! Will re-open it if this will be a release blocker.
/reopen
Reopened this issue. <detailsIn response to : /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
This seems like a flaky test. It has failed multiple times: cc
/remove-kind failing-test /kind flake
The load balancer tkes a lot of time to be provisioned and the test times out I'm going to bump the ingress-gce version used on the test because is too old and has some performance improvements that can solve this issue
/reopen we need to be completely sure this address the problem, it has to get at least 5/5 consecutive greens
Reopened this issue. <detailsIn response to : /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
It failed again:
Checking last occurrence we can find the logs on the kube-controller-manager So, the problem is that the time to acquire the IP takes too much, the test times out at and the IP is at IIUIC this depends on the underlay infra, what do we want to do with this, bump the timeout of the LB?
/assign
Update on the state of failures. The failures are becoming more frequent: !
Unfortunately I think bumping the timeout is our only option.
can you send a PR to move to 1 hours and add a comment referencing this issue?
Just created
CI is green since 06-27. /close
Closing this issue. <detailsIn response to : CI is green since 06-27. /close 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

Discussion:
terminationGracePeriodSeconds: 600 hostNetwork: true containers: <del> - image: gcr.io/k8s-ingress-image-push/ingress-gce-glbc-amd64:v1.20.1 </del> <ins> - image: gcr.io/k8s-ingress-image-push/ingress-gce-glbc-amd64:v1.23.1 </ins> livenessProbe: httpGet: path: /healthz

- --running-in-cluster=false - --config-file-path=/etc/gce.conf - --healthz-port=8086 <del> - --enable-endpoint-slices </del> - --gce-ratelimit=ga.Operations.Get,qps,10,100 - --gce-ratelimit=alpha.Operations.Get,qps,10,100 - --gce-ratelimit=beta.Operations.Get,qps,10,100