-
Notifications
You must be signed in to change notification settings - Fork 84
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
feat(client): kube-api timeout requests #627
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: genofire <geno+dev@fireorbit.de>
@stefanprodan any feedback? |
All API calls that Flux makes use a Go context with a timeout, the timeout is set to the value supplied by users in each Flux CR using |
where is this timeout set? in it is used an |
The context comes from controller runtime, e.g. https://github.com/fluxcd/kustomize-controller/blob/385df6785d602eed39ffd7310be021c1ef2d518b/internal/controller/kustomization_controller.go#L165 |
sorry, i mean - where is the context created? (for my problem inside of source-controller for helmrepos). |
@hiddeco @darkowlzz any idea how SC could get stuck forever when reconciling Helm repos? |
Going by the information in this comment fluxcd/source-controller#1173 (comment) , it may not be stuck. It's more likely to have entered into a considerably long exponential back-off after failing for a few times. If the reconciliation is stuck, manually triggering a reconciliation would not result in a reconciliation to start as the controller-runtime workqueue groups jobs for the same object together and one object can't be processed in parallel. It would help to gather more information about the behavior by isolating the scenario and sharing related logs, events and object status when this happens. If manually triggering reconciliation works, the object should be able to reconcile on its own after some time. The max retry delay can also be configured to reduce this back-off time using the flag:
But one of the comment mentioned that the secrets were available for 31 minutes. 15 minutes of max retry delay shouldn't be an issue in that case. Maybe you need to increase the concurrency of the controller, in case it's busy reconciling other objects, using the flag:
|
No description provided.