Default error_policy could be defined in Controller builder

[clux]

As it stands the error_policy fn for Controller is not async, so it's actually hard to do anything useful inside of them short of changing/retrieving state (and even that can be hard if it's locked), so can only see it being useful to return an instance of the enum, possibly keeping track of backoff numbers in Context.

I think we could have two builder variants here:

• Controller::new(...).error_policy(myReconcileAction) (flat retry / backoff retry ideally configurable)
• Controller::new(...).error_handler(my_async_error_handler)

The first one provides an easy way to replace, and the builder can guarantee we only use one. (It can in fact turn it into the second).

The second is then used, but might require some rejigging of how the function is called within the applier.

[nightkr]

I've been looking at implementing an error_policy on top of backoff. It mostly seems to work, just need to get around to hooking it all together.

[pando85]

I just hit this situation where a backoff policy per object would be great in case of a reconciliation error.

What would be the steps to move this forward after all the changes have been made to kube-rs since this issue was created?

[clux]

We didn't really get too far with this, unfortunately. It's perhaps a little overkill to have by default - I've generally used fixed 300s requeues for failures and that's usually OK. We also gotta replace the backoff library first #1635

That said, a pattern I've seen used is to make the reconciler (which is async) be a fn that wraps an inner_reconciler (which does the regular reconciliation and returns a regular error). Then the outer fn can call the inner reconciler, keep track of those errors, and return appropriate Action::requeue durations there, kind of bypassing the need for an error_policy.

If you want you could do a per-gvk/per-object hashmap there and create backoffs - possibly storing it on the controller context.

[pando85]

@clux , thanks for your comment. It really clarifies to me how to proceed with this.

In that case I don't know if make sense just to close this as we have to handle this outside the project because not all people need it and the controller is flexible enough for this implementation.

Also, good point about the backon crate. I will take a look.

[pando85]

If someone needs to implement something similar, I finally follow @clux advice.

I created a wrapper function for reconciler.

And implemented a backoff per object.

For a more detailed explanation, all the changes can be found in this commit.