-
Notifications
You must be signed in to change notification settings - Fork 38.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
kubectl wait --for
flag help text improvements
#122319
base: master
Are you sure you want to change the base?
Conversation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
Hi @omertuc. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: omertuc The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Two changes: * Changed wording `The default condition-value is true` to `...is True` instead, as in status conditions the `status` field has a string type and not a boolean type. and in the apimachinery meta v1 constant `ConditionTrue` the value is uppercase: `"True"`. Reading it in the help text with lowercase gave me the impression that it's a boolean value and not a string value, or even if it were a string then that it should be lowercase `"true"`. I feel that when it's written in uppercase that confusion is eliminated somewhat * Added a remark about how generation comparison works. I was stumped by why my wait call would timeout, because when I looking at the resource condition in practice with `kubectl get` it seemed to match my `wait` query. I had to dig in the `kubectl` source code to find that it also takes `observedGeneration` into account to realize I was timing out because the condition's generation was not being updated correctly by the controller.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this 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/test-infra repository. |
/reopen |
@omertuc: Reopened this 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/test-infra repository. |
/remove-lifecycle rotten |
Please note that we're already in Test Freeze for the Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Wed Apr 3 02:18:49 UTC 2024. |
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Two changes:
Changed wording
The default condition-value is true
to...is True
instead, as in status conditions the
status
field has a string typeand not a boolean type. and in the apimachinery meta v1 constant
ConditionTrue
the value is uppercase:"True"
. Reading it in thehelp text with lowercase gave me the impression that it's a boolean
value and not a string value, or even if it were a string then that it
should be lowercase
"true"
. I feel that when it's written inuppercase that confusion is eliminated somewhat
Added a remark about how generation comparison works. I was stumped by
why my wait call would timeout, because when I looking at the resource
condition in practice with
kubectl get
it seemed to match mywait
query. I had to dig in the
kubectl
source code to find that it alsotakes
observedGeneration
into account to realize I was timing outbecause the condition's generation was not being updated correctly by
the controller.
Which issue(s) this PR fixes:
N/A
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: