-
Notifications
You must be signed in to change notification settings - Fork 78
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
Tech Debt: Rename prune/delete timeout to reconcile timeout #441
Comments
An alternate option here is to remove DeleteTimeout/PruneTimeout completely and replace them with the existing ReconcileTimeout. @haiyanmeng @ash2k Would this be acceptable for your use cases or do you need the timeouts to remain separate? |
@karlkfi Appreciate the ping. Conceptually it may make sense for each logically separate "thing"/step to have a separate timeout. I don't know if it's hard or easy to achieve this, haven't checked the code. In practice though my program passes a context to the applier run and cancels it when it needs to stop the applier (when program is terminating or when another set of objects need to be synced instead of the one that is currently being applied).
Are you suggesting |
We already allow a global applier timeout using context.WithTimeout (which it sounds like you're using already). The proposal is either: DeleteTimeout & PruneTimeout both come from the WaitTask, one from the destroyer and one from the applier, so the differentiation is already confusing. Even if we do either of these, there's still a difference between the DeleteEvent (destroyer) and PruneEvent (applier), even though they both come from the PruneTask. I would like to make them both a DeleteEvent for consistency, but I wasn't sure I wanted to make both API changes at the same time. |
BTW, I don't think this is very high priority. |
Agreed on it being low priority. It was just surfaced as tech debt from one of my previous PRs. The problem with the current naming is:
If I were setting a DeleteTimeout, I would expect it to include the DELETE call, but it does not. It only includes the waiting afterwards. This has come up as being confusing several times when trying to explain how the applier actually works. Perhaps you would prefer WaitTimeout for both applying and deleting? |
Ok, so new proposal: How about we just use "Reconcile[d]" for both ideas. This is what I've done for the new WaitEvent operations in #463 So this would mean combining the reconcile/prune/delete timeout configs into one |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
As a new user to this code base (through kpt & Config Sync), I was initially really confused about the difference between destroy, prune, and delete. And as a contributor, I have a hard time documenting/explaining the waiting behavior after deletion.
Solution:
Both of these changes would be interface changes, for options and events, but I think the improved clarity will be worth it.
Destroy is also another synonym for delete, but in this context it means to delete a whole inventory, so we don't need to change that. I think it's easy to describe how destroy is different from delete/prune/elimination.
/cc @seans3 @mortent
The text was updated successfully, but these errors were encountered: