Deployment error recovery

[Evynglais]

Bug description

Hi,

I've noticed some issues with build recovery. Firstly, it's not configurable (given the TODO in recovery.go); secondly, the defaults are very quick, and also mis-configured (min > max). Finally, it should give the option to backoff indefinitely.

I'm working on a PR that addresses these.

Thanks,
Evyn

Camel K or runtime version

2.10.0

[squakez]

I think this feature should be removed instead, see #6575. The problem is that a failing build is likely to fail indefinitely, so, it does not make sense to start over again. What I think you're seeing is a problem within deployment, for which, a new reconciliation should be rescheduled within some time when it fails for any reason (i.e., some missing resource like I understand it can be your use case).

[squakez]

The entire discussion available in this chat thread: https://camel.zulipchat.com/#narrow/channel/257299-camel-k/topic/Integration.20Builder.20Recovery/with/593474397

The idea is that whenever there is a "deployment" error (ie, a failure on trait application for any reason), we should apply an esponential backoff retry. We may need to distinguish the generic "Error" state we are returning now with something more specific, "DeploymentError" and "RuntimeError". With this error definition we can provide more easily a controller handler only for the former kind of error (as "RuntimeError" are already managed by reconciliation triggered by Pod restart).

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!