Skip to content
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

placeholder: can kapp-controller signal kapp to transiently suppress failures when success is expected to take a few cycles? #349

Open
joe-kimmel-vmw opened this issue Aug 24, 2021 · 4 comments
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed dk-think-more enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome.

Comments

@joe-kimmel-vmw
Copy link
Contributor

Describe the problem/challenge you have
Users of kapp-controller, including UI dashboards that rely on kapp-controller under the hood, often see a "reconcile failed" message which resolves into a "reconcile succeeded" message if they wait for some tens of seconds. This false failure undermines user confidence and presents rough edges to end-users.

Describe the solution you'd like
Are there case where kapp-controller "knows" that it's very likely to take a few retry cycles, e.g. when we first have to resolve image pull secrets? If we can recognize those cases, can we invoke kapp with a flag along the lines of "show_failures_as_retries=5" and then kapp will either leave the status as "Reconciling" or update to e.g. "Retrying Reconciling" (might want to discuss with users whether intermediate state would be useful in their UX) until after N failures.

Anything else you would like to add:
[Additional information that will assist in solving the issue.]


Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@joe-kimmel-vmw joe-kimmel-vmw added enhancement This issue is a feature request carvel-triage This issue has not yet been reviewed for validity labels Aug 24, 2021
@aaronshurley aaronshurley added priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome. carvel-accepted This issue should be considered for future work and that the triage process has been completed and removed carvel-triage This issue has not yet been reviewed for validity labels Aug 25, 2021
@aaronshurley
Copy link
Contributor

Accepting this issue and moving it to the unprioritized backlog, for now. If we receive more signal for this feature then we can bump the priority.

@joe-kimmel-vmw
Copy link
Contributor Author

just to push a little on signal, this something that I saw previously and that 100+ people saw during a live demo of TMC, which the primary demo-driver wasn't ready for but which their secondary driver was basically expecting. Respect we may still wait to prioritize relative to other incoming signals.

@aaronshurley
Copy link
Contributor

Thanks @joe-kimmel-vmw for the additional info. I'd be inclined towards increasing the priority of this issue or at least more closely monitoring this issue in the near term so that we can move quickly.

@vibhas thoughts?

@vibhas
Copy link

vibhas commented Aug 30, 2021

I agree this is important. I would say that let's closely monitor this issue for now and then prioritize it based on a bit more evidence and feedback.

@aaronshurley aaronshurley moved this to To Triage in Carvel Aug 18, 2022
@github-project-automation github-project-automation bot moved this to To Triage in Carvel Feb 14, 2023
@neil-hickey neil-hickey added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Feb 22, 2023
@neil-hickey neil-hickey moved this from To Triage to Unprioritized in Carvel Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed dk-think-more enhancement This issue is a feature request priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. priority/unprioritized-backlog Higher priority than priority/awaiting-more-evidence but not planned. Contributions are welcome.
Projects
Status: Unprioritized
Development

No branches or pull requests

5 participants