-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
etcdctl: use user specified timeout value #3518
Conversation
On the second thought, |
After reading through the code, I think etcdctl correctly set the That timeout is a pre request timeout. etcdctl might send out multiple requests if it fails to connection the first few endpoints. What you have changed is a total timeout for the RPC. We have not defined the flag for that timeout yet. |
Yes, per request timeout seems to be configured correctly. However, current etcdctl use 1s as total timeout for RPC and it causes unreasonable timeout (I found this issue with testing with this tool: https://github.com/osrg/earthquake , the tool can test various execution pattern of distributed systems. I'll share the test code later). It means even user passes --timeout 5s, etcdctl causes timeout in 1s. Therefore I think providing a flag for configuring timeout of whole RPC or not configuring timeout would be reasonable. How do you think? |
The client.DefaultRequestTimeout is 5s, so etcdctl should cause timeout in 5s. Do you observe 1s behavior? |
@yichengq But we should support total-timeout right? |
@xiang90 Yes. 5s could be a default value, and users could customize the total timeout. |
Or should etcdctl remove total timeout (allow unbounded timeout for total execution time)? |
@mitake I would suggest a 5 second default total-timeout and make the total-timeout also a flag and configurable. |
etcdctl should use a user specified timeout value. This commit adds a new option --total-timeout to the command. The value passed via this option is used as a timeout value of entire RPC (API call of client). Fixes etcd-io#3517
@@ -40,6 +40,7 @@ func main() { | |||
cli.StringFlag{Name: "ca-file", Value: "", Usage: "verify certificates of HTTPS-enabled servers using this CA bundle"}, | |||
cli.StringFlag{Name: "username, u", Value: "", Usage: "provide username[:password] and prompt if password is not supplied."}, | |||
cli.DurationFlag{Name: "timeout", Value: time.Second, Usage: "connection timeout per request"}, | |||
cli.DurationFlag{Name: "total-timeout", Value: time.Second * 5, Usage: "timeout of entire RPC execution"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5 * time.Second
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
timeout for the command execution (except watch)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5 * time.Second
ok, I'll fix.
timeout for the command execution (except watch)
Actually the timeout value corresponds to one RPC (functions defined in client/). If we call the RPC (potentially which can consist multiple requests?) as command, your description is right. However, I'm not sure it is suitable or not.
Or should we use one context object per one command execution? I think this direction would be natural for users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or should we use one context object per one command execution? I think this direction would be natural for users.
I think so.
I created a new PR for this problem: #3530 Could you review the new one? The contents of two PR are so different. |
etcdctl should use a timeout value specified with the option --timeout
Fixes #3517
If the current behavior is intentional, please ignore it.