Bump the GCE metadata server timeout to 2s. #114
Conversation
| std::string Environment::GetMetadataString(const std::string& path) const { | ||
| http::client::options options; | ||
| http::client client(options.timeout(1)); | ||
| http::client client(options.timeout(2)); |
There was a problem hiding this comment.
This would require more changes, but can we set this to be a configuration value instead? I'm hoping 2 is adequate for now, but should the metadata latency increase again, it would be nice to make a simple PSA to update the timeout, instead of requiring an entirely new binary.
There was a problem hiding this comment.
I've thought about this too, but it seems like this will not be a regular occurrence, and I would rather not add gratuitous options. Besides, in the Kubernetes world, a config bump and a binary bump require about the same amount of effort (i.e., a PR with a config change). WDYT?
There was a problem hiding this comment.
+1 to what Igor said. My argument against that is that this is only a timeout upper bound. If the metadata server timeout starts taking longer than say ~5 seconds we will have other bigger changes to potentially consider.
There was a problem hiding this comment.
I argue a user should have a temporary remedy as an option, with the current approach it requires the user to be broken until we ship out a fix. Updating a configmap / command line arg is not a big deal, compared to being blocked by a GCP bug while they figure out how to reduce their latency. Giving the user an option to become unblocked is better for our users.
There was a problem hiding this comment.
We have plenty of other timeouts in the code that aren't controllable via options. This one is so minor, that I would rather not bring it up to our users' attention. As Dhrupad says, if the metadata server takes that long, something else is terribly broken.
3 participants
No description provided.