-
Notifications
You must be signed in to change notification settings - Fork 454
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
Add --pull-timeout
flag to crictl
create
, run
and pull
commands
#1448
Add --pull-timeout
flag to crictl
create
, run
and pull
commands
#1448
Conversation
b57b2b0
to
ac5230a
Compare
LGTM |
Should we make it a part of critest? Not sure how we will test the behavior, but at least runtime should stop processing and exit when requested. |
@@ -633,7 +641,7 @@ func normalizeRepoDigest(repoDigests []string) (string, string) { | |||
|
|||
// PullImageWithSandbox sends a PullImageRequest to the server, and parses | |||
// the returned PullImageResponse. | |||
func PullImageWithSandbox(client internalapi.ImageManagerService, image string, auth *pb.AuthConfig, sandbox *pb.PodSandboxConfig, ann map[string]string) (*pb.PullImageResponse, error) { | |||
func PullImageWithSandbox(client internalapi.ImageManagerService, image string, auth *pb.AuthConfig, sandbox *pb.PodSandboxConfig, ann map[string]string, timeout time.Duration) (*pb.PullImageResponse, error) { |
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.
I wonder what should be a behavior on Ctrl+C
. Should we have a context cancelled as well?
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.
Interesting idea, I don't think we consider Ctrl+C in any RPC for now (means the RPC will run through but we will not catch the result). We can probably follow-up on that and add it to all commands.
&cli.DurationFlag{ | ||
Name: "cancel-timeout", | ||
Aliases: []string{"T"}, | ||
Usage: "Seconds to wait for a container create request to complete before cancelling the request", |
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.
should it say - "disabled if 0" as well?
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 anything about the default
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.
The help mentions the default value:
--pull-timeout value, --pt value Maximum time to be used for pulling the image, disabled if set to 0s (default: 0s) [$CRICTL_PULL_TIMEOUT]
@@ -111,6 +114,17 @@ var createPullFlags = []cli.Flag{ | |||
Value: "", | |||
Usage: "Use `USERNAME` for accessing the registry. The password will be requested on the command line", | |||
}, | |||
&cli.DurationFlag{ |
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.
I wonder if we need two of those or just one parameter timeout
will be enough? Are those two having different semantics?
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.
Technically we now have three per subcommand:
- the
--timeout
/-t
flag on the root level (default 2s) - a command specific timeout
crictl create
: a--cancel-timeout
/-T
flag which overrides the root flag (default 0s, but inherits the 2s from the root flag)crictl run
: a--timeout
/-t
flag which overrides the root flag (default 0s, but inherits the 2s from the root flag)
- the
--pull-timeout
/-pt
flag, specific for the image pull
Merging the pull timeout with the existing ones would probably break most users since a pull in 2s is unlikely per default. So adding another timeout seemed to be reasonable, because it will default to 0s
as the previous behavior (no pull timeout) and can be adjusted as being set.
…ands This allows to set a pull context timeout for the supported commands. Runtimes may or may not use the timeout from the RPC for image pulls, but `crictl` should generally support that feature. Signed-off-by: Sascha Grunert <[email protected]>
ac5230a
to
780d044
Compare
Yes, I added a critest case for that. |
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: saschagrunert, SergeyKanzhelev The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This allows to set a pull context timeout for the supported commands. Runtimes may or may not use the timeout from the RPC for image pulls, but
crictl
should generally support that feature.Which issue(s) this PR fixes:
None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?