You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/documentation/patterns-best-practices.md
+18-2
Original file line number
Diff line number
Diff line change
@@ -84,7 +84,7 @@ possible to completely deactivate the feature, though we advise against it. The
84
84
configure automatic retries for your `Reconciler` is due to the fact that errors occur quite
85
85
often due to the distributed nature of Kubernetes: transient network errors can be easily dealt
86
86
with by automatic retries. Similarly, resources can be modified by different actors at the same
87
-
time so it's not unheard of to get conflicts when working with Kubernetes resources. Such
87
+
time, so it's not unheard of to get conflicts when working with Kubernetes resources. Such
88
88
conflicts can usually be quite naturally resolved by reconciling the resource again. If it's
89
89
done automatically, the whole process can be completely transparent.
90
90
@@ -94,7 +94,7 @@ Thanks to the declarative nature of Kubernetes resources, operators that deal on
94
94
Kubernetes resources can operator in a stateless fashion, i.e. they do not need to maintain
95
95
information about the state of these resources, as it should be possible to completely rebuild
96
96
the resource state from its representation (that's what declarative means, after all).
97
-
However, this usually doesn't hold true anymore when dealing with external resources and it
97
+
However, this usually doesn't hold true anymore when dealing with external resources, and it
98
98
might be necessary for the operator to keep track of this external state so that it is available
99
99
when another reconciliation occurs. While such state could be put in the primary resource's
100
100
status sub-resource, this could become quickly difficult to manage if a lot of state needs to be
@@ -105,3 +105,19 @@ advised to put such state into a separate resource meant for this purpose such a
105
105
Kubernetes Secret or ConfigMap or even a dedicated Custom Resource, which structure can be more
106
106
easily validated.
107
107
108
+
## Stopping (or not) Operator in case of Informer Errors
109
+
110
+
It can
111
+
be [configured](https://github.com/java-operator-sdk/java-operator-sdk/blob/2cb616c4c4fd0094ee6e3a0ef2a0ea82173372bf/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/ConfigurationService.java#L168-L168)
112
+
if the operator should stop in case of any informer error happens on startup. By default, if there ia an error on
113
+
startup and the informer for example has no permissions list the target resources (both the primary resource or
114
+
secondary resources) the operator will stop instantly. This behavior can be altered by setting the mentioned flag
115
+
to `false`, so operator will start even some informers are not started. In this case - same as in case when an informer
116
+
is started at first but experienced problems later - will continuously retry the connection indefinitely with an
117
+
exponential backoff. The operator will just stop if there is a fatal
0 commit comments