Fix GCE client long polling timeouts. #6783
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind bug
/kind regression
What this PR does / why we need it:
At the moment GCE manager is using 30 seconds timeouts for all http calls which breaks logic of long polling WAIT calls for GCE API as in the worst case scenario they require 2 minutes.
This PR increases http timeout to be 3 minutes (2 minutes + buffer time) and adds timeouts control over some operations in order to avoid performance degradation in the case of not responding API. Not all the methods can be patched, as with pagination we are not sure what would be the exact number of calls and current GCE API doesn't provide a way to control per call timeouts.
Special notes for your reviewer:
gce.New
to usegce.NewService
http.Client.Timeout
affects operation callsDoes this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: