-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
kubectl wait: Introduce --wait-for-creation flag #122994
kubectl wait: Introduce --wait-for-creation flag #122994
Conversation
0594661
to
e9a9207
Compare
/triage accepted |
@ardaguclu: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
e9a9207
to
d1408d1
Compare
/priority important-longterm |
b474a40
to
17cd4de
Compare
17cd4de
to
7a8faf9
Compare
kubectl wait command errors out when the waited resource does not exist. But we need to provide a way to the users about intentionally also waiting for the creation of resources. This PR introduces a new flag to cover waiting for the creation of resources with preserving the default behavior.
7a8faf9
to
e24b9a0
Compare
unrelated |
@ardaguclu: you cannot LGTM your own PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
not lgtm :) |
It's all green! Thanks @ardaguclu |
/release-note-edit
|
/release-note-edit
|
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.
Nice work!
/lgtm
LGTM label has been added. Git tree hash: 8fa76aa7cbf4937ba3ada79a9b65f40bdf7d43c1
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ardaguclu, eddiezane 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 |
@@ -320,6 +328,40 @@ func (o *WaitOptions) RunWait() error { | |||
ctx, cancel := watchtools.ContextWithOptionalTimeout(context.Background(), o.Timeout) | |||
defer cancel() | |||
|
|||
isForDelete := strings.ToLower(o.ForCondition) == "delete" | |||
if o.WaitForCreation && o.Timeout == 0 { | |||
return fmt.Errorf("--wait-for-creation requires a timeout value greater than 0") |
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.
This is a regressing change for folks using --timeout=0
as documented:
The length of time to wait before giving up. Zero means check once and don't wait.
Previously, this would check a condition once:
kubectl wait --for=condition=Available deployments --all --timeout=0
Now, it fails with:
error: --wait-for-creation requires a timeout value greater than 0
I'm not sure defaulting WaitForCreation to true is compatible here. Rollback in #125630 with a test added to exercise the --timeout=0
case so this can be brought back in more compatibly.
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.
Does that mean if the timeout=0, we should ignore the waitforcreation step and mention this in the flag description?
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.
Because when timeout=0, ConditionFn
will be executed once and returns
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.
yeah, it (L:336) should be something like this;
if o.WaitForCreation && !isForDelete && o.Timeout != 0 {
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.
Please use the new
--wait-for-creation=false
flag for the previous behavior of immediately failing if the specified resource does not yet exist.
That sounds like this is changing existing behavior, which doesn't really match the description of This PR introduces new --wait-for-creation flag to also wait for the creation of resources with preserving the default behavior.
Would it be simpler and more compatible to default WaitForCreation to false? Then that would be reasonable to forbid WaitForCreation and Timeout of 0, or WaitForCreation and isForDelete.
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 agree with you. Besides, we can change the default separately in the future after carefully considering what we should do for such cases.
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.
@eddiezane what do you think about bringing same PR back just the default value is false?
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR introduces new
--wait-for-creation
flag to also wait for the creation of resources withpreserving the default behavior.
Which issue(s) this PR fixes:
Fixes kubernetes/kubectl#1516, kubernetes/kubectl#1487
Does this PR introduce a user-facing change?
(release note cleared since this was rolled back in #125630, original release note below)