Skip to content

Commit 0563e0e

Browse files
committed
docs: retry + reschedule (#670)
1 parent cd0d9a7 commit 0563e0e

File tree

1 file changed

+30
-1
lines changed

1 file changed

+30
-1
lines changed

docs/documentation/features.md

Lines changed: 30 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -97,6 +97,9 @@ In this case first the custom resource is updated then the status in two separat
9797

9898
Always update the custom resource with `UpdateControl`, not with the actual kubernetes client if possible.
9999

100+
On custom resource updates there is always an optimistic version control in place, to make sure that another update is
101+
not overwritten (by setting `resourceVersion` ) .
102+
100103
The `DeleteControl` typically instructs the framework to remove the finalizer after the dependent resource are
101104
cleaned up in `deleteResource` implementation.
102105

@@ -107,10 +110,36 @@ operation is initiated. Note that in this case you might want to either schedule
107110

108111
## Automatic Retries on Error
109112

110-
### Correctness and automatic retry
113+
When an exception is thrown from a controller, the framework will schedule an automatic retry of the reconciliation.
114+
The retry is behavior is configurable, an implementation is provided that should cover most of the use-cases, see
115+
[GenericRetry](https://github.com/java-operator-sdk/java-operator-sdk/blob/master/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/retry/GenericRetry.java)
116+
But it is possible to provide a custom implementation.
117+
118+
It is possible to set a limit on the number of retries. In the [Context](https://github.com/java-operator-sdk/java-operator-sdk/blob/master/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/Context.java)
119+
object information is provided about the retry, particularly interesting is the `isLastAttempt`, since a behavior
120+
could be implemented bases on this flag. Like setting an error message in the status in case of a last attempt;
121+
122+
Event if the retry reached a limit, in case of a new event is received the reconciliation would happen again, it's
123+
just won't be a result of a retry, but the new event.
124+
125+
A successful execution resets the retry.
126+
127+
### Correctness and Automatic Retries
128+
129+
There is a possibility to turn of the automatic retries. This is not desirable, unless there is a very specific
130+
reason. Errors naturally happen, typically network errors can cause some temporal issues, another case is when a
131+
custom resource is updated during the reconciliation (using `kubectl` for example), in this case
132+
if an update of the custom resource from the controller (using `UpdateControl`) would fail on a conflict. The automatic
133+
retries covers these cases and will result in a reconciliation, even if normally an event would not be processed
134+
as a result of a custom resource update from previous example (like if there is no generation update as a result of the
135+
change and generation filtering is turned on)
111136

112137
## Re-Scheduling Execution
113138

139+
In simple operators one way to implement an operator is to periodically reconcile it. This is supported explicitly by
140+
`UpdateControl`, see method: `public UpdateControl<T> withReSchedule(long delay, TimeUnit timeUnit)`.
141+
This would schedule a reconciliation to the future.
142+
114143
## Retry and Re-Scheduling Common Behavior
115144

116145
## Handling Related Events with Event Sources

0 commit comments

Comments
 (0)