From cfc6b98a404f1d0a374b10900dc3f8b1b41b7031 Mon Sep 17 00:00:00 2001 From: csviri Date: Wed, 10 Nov 2021 13:44:59 +0100 Subject: [PATCH 1/3] docs: retry --- docs/documentation/features.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/docs/documentation/features.md b/docs/documentation/features.md index 7886ec0328..7233e22b88 100644 --- a/docs/documentation/features.md +++ b/docs/documentation/features.md @@ -107,12 +107,40 @@ operation is initiated. Note that in this case you might want to either schedule ## Automatic Retries on Error +When an exception is thrown from the controller, the framework will do an automatic retry of the reconciliation. +The retry is behavior is configurable, an implementation is provided that should cover most of the use-cases, see +[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) +But it is possible to provide a custom implementation. + +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) +object information is provided about the retry, particularly interesting is the `isLastAttempt`, since a behavior +could be implemented in case this is the last attempt, like setting an error message into status of the resource. + +Event if the retry reached a limit, in case of a new event is received the reconciliation would happen again, it's +just won't be a result of a retry, but the new event. + +A successful execution resets the retry. + ### Correctness and automatic retry +There is a possibility to turn of the automatic retries. This is not desirable, unless there some very specific +reason. Errors naturally happen, typically network errors can cause some temporal issues, but +another case is when a custom resource is updated during the reconciliation (using `kubectl` for example), in this case +if an update of the custom resource from the controller (using `UpdateControl`) would fail on a conflict. The automatic +retries covers these cases and will result in a reconciliation. Even if normally an event would not be processed +as a result of a custom resource update from previous example (like if there is no generation update as a result of the +change and generation filtering is turned on) + ## Re-Scheduling Execution +In simple operators one way to implement an operator is to periodically reconcile it. This is supported explicitly by +`UpdateControl`, see method: `public UpdateControl withReSchedule(long delay, TimeUnit timeUnit)`. +This would schedule a reconciliation to the future. + ## Retry and Re-Scheduling Common Behavior + + ## Handling Related Events with Event Sources ### Caching and Event Sources @@ -123,6 +151,7 @@ operation is initiated. Note that in this case you might want to either schedule ## Monitoring with Micrometer +## Advanced Behavior From 57d867b8f49f5e372dd2b6bb0830f3e8e243df06 Mon Sep 17 00:00:00 2001 From: csviri Date: Wed, 10 Nov 2021 14:03:45 +0100 Subject: [PATCH 2/3] docs: wip --- docs/documentation/features.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/documentation/features.md b/docs/documentation/features.md index 7233e22b88..adf691d135 100644 --- a/docs/documentation/features.md +++ b/docs/documentation/features.md @@ -97,6 +97,9 @@ In this case first the custom resource is updated then the status in two separat Always update the custom resource with `UpdateControl`, not with the actual kubernetes client if possible. +On custom resource updates there is always an optimistic version control in place, to make sure that another update is +not overwritten (by setting `resourceVersion` ) . + The `DeleteControl` typically instructs the framework to remove the finalizer after the dependent resource are cleaned up in `deleteResource` implementation. @@ -140,7 +143,6 @@ This would schedule a reconciliation to the future. ## Retry and Re-Scheduling Common Behavior - ## Handling Related Events with Event Sources ### Caching and Event Sources From d4dcf73f6d9ee6a95c1c90a849a9668028239323 Mon Sep 17 00:00:00 2001 From: csviri Date: Wed, 10 Nov 2021 14:16:01 +0100 Subject: [PATCH 3/3] docs: improvements --- docs/documentation/features.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/docs/documentation/features.md b/docs/documentation/features.md index adf691d135..a2a0b3a378 100644 --- a/docs/documentation/features.md +++ b/docs/documentation/features.md @@ -110,27 +110,27 @@ operation is initiated. Note that in this case you might want to either schedule ## Automatic Retries on Error -When an exception is thrown from the controller, the framework will do an automatic retry of the reconciliation. +When an exception is thrown from a controller, the framework will schedule an automatic retry of the reconciliation. The retry is behavior is configurable, an implementation is provided that should cover most of the use-cases, see [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) But it is possible to provide a custom implementation. 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) object information is provided about the retry, particularly interesting is the `isLastAttempt`, since a behavior -could be implemented in case this is the last attempt, like setting an error message into status of the resource. +could be implemented bases on this flag. Like setting an error message in the status in case of a last attempt; Event if the retry reached a limit, in case of a new event is received the reconciliation would happen again, it's just won't be a result of a retry, but the new event. A successful execution resets the retry. -### Correctness and automatic retry +### Correctness and Automatic Retries -There is a possibility to turn of the automatic retries. This is not desirable, unless there some very specific -reason. Errors naturally happen, typically network errors can cause some temporal issues, but -another case is when a custom resource is updated during the reconciliation (using `kubectl` for example), in this case +There is a possibility to turn of the automatic retries. This is not desirable, unless there is a very specific +reason. Errors naturally happen, typically network errors can cause some temporal issues, another case is when a +custom resource is updated during the reconciliation (using `kubectl` for example), in this case if an update of the custom resource from the controller (using `UpdateControl`) would fail on a conflict. The automatic -retries covers these cases and will result in a reconciliation. Even if normally an event would not be processed +retries covers these cases and will result in a reconciliation, even if normally an event would not be processed as a result of a custom resource update from previous example (like if there is no generation update as a result of the change and generation filtering is turned on) @@ -142,7 +142,6 @@ This would schedule a reconciliation to the future. ## Retry and Re-Scheduling Common Behavior - ## Handling Related Events with Event Sources ### Caching and Event Sources