-
Notifications
You must be signed in to change notification settings - Fork 79
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
Bug: kstatus/status returns incorrect "Current" result immediately after DaemonSet apply #548
Comments
Maybe we can use |
rohitagarwal003
added a commit
to rohitagarwal003/cli-utils
that referenced
this issue
Feb 18, 2022
In status.Compute() -> checkGenericProperties() -> checkGeneration(), we check that metadata.generation is equal to status.observedGeneration but don't return an InProgress status if either of them is unset. This may be reasonable for generic resource where we are unsure if these fields would be set, but for daemonsets, we *know* that these fields get set by the controller and so we should ensure that. This fixes kubernetes-sigs#548.
rohitagarwal003
added a commit
to rohitagarwal003/cli-utils
that referenced
this issue
Feb 18, 2022
In status.Compute() -> checkGenericProperties() -> checkGeneration(), we check that metadata.generation is equal to status.observedGeneration but don't return an InProgress status if either of them is unset. This may be reasonable for generic resource where we are unsure if these fields would be set, but for daemonsets, we *know* that these fields get set by the controller and so we should ensure that. This addresses kubernetes-sigs#548
rohitagarwal003
added a commit
to rohitagarwal003/cli-utils
that referenced
this issue
Feb 18, 2022
In status.Compute() -> checkGenericProperties() -> checkGeneration(), we check that metadata.generation is equal to status.observedGeneration but don't return an InProgress status if either of them is unset. This may be reasonable for generic resource where we are unsure if these fields would be set, but for daemonsets, we *know* that these fields get set by the controller and so we should ensure that. This addresses kubernetes-sigs#548
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a use case where we want to create a DaemonSet and wait for its replicas to be ready before moving forward with the rest of the work. I was trying to use the
kstatus/status
library to do that. I thought I would apply the DaemonSet and then continuously check the result returned bystatus.Compute()
.However, immediately after applying the DaemonSet, the
status.Compute()
method returns aCurrent
result seemingly because the status is:status:map[currentNumberScheduled:0 desiredNumberScheduled:0 numberMisscheduled:0 numberReady:0]]}
Is this expected? Should we add an exception case to return an
InProgress
result whendesiredNumberScheduled == 0
?Here's the code I was using:
Here's the output of the run:
Because I had a "bad" DaemonSet that didn't start, if I run the program again, it worked correctly:
The text was updated successfully, but these errors were encountered: