-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
boskos/janitor fails to clean up some resources in a timely manner if dirty rates are unequal #15925
Comments
Another example of how we can get into a bad state (which we're hitting today on one of our deployments): if a janitor is configured to clean many resource types, and one resource type is constantly failing to clean, all janitor replicas may eventually get stuck trying to clean up that resource type, to the exclusion of all others. |
Couldn't we also change the janitor to run a watch on resources and use a workqueue/pool to handle resources? That should make better guarantees about QoS as well as record the number of failure attempts on a resource and give up on it at an acceptable time./ |
Probably. Currently the janitor interfaces through the Boskos HTTP API, but if we switch to just relying on the CRDs as the source of truth, we can probably make things scale more effectively. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Moving to kubernetes-sigs/boskos#17. |
@ixdy: Closing this issue. 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. |
Creating a one-sentence summary of this issue is hard, but the basic bug is fairly easy to understand.
Assume a Boskos instance has three resource types, A, B, and C. A has 5 resources, B has 10, and C has 100. A Boskos janitor has been configured to clean all three types.
Currently, the janitor loops through all resource types, iteratively cleaning one resource of each type. If the janitor finds that one of the types has no dirty resources, it stops querying that resource type until all resources have been cleaned, at which point it waits a minute and then starts over with the complete list again.
In our hypothetical case (as well as observed in practice), what this means is that the janitor will finish cleaning resources of type A (and possibly B), while still having many more C resources to clean. Additionally, given that C is such a large pool, there will likely be many jobs making more C resources dirty. As a result, it will be quite some time before the janitor attempts to clean A resources, and the pool will probably fill up with dirty resources.
Possible ways to mitigate the issue (in increasing complexity):
/area boskos
The text was updated successfully, but these errors were encountered: