@@ -460,16 +460,19 @@ For more information about MDC see this [link](https://www.baeldung.com/mdc-in-l
460
460
461
461
## Dynamically Changing Target Namespaces
462
462
463
- A controller can be configured to watch a set of namespaces (not only a single namespace or the whole cluster).
464
- The framework supports to dynamically change the list of these namespaces while the operator is running.
465
- When a reconciler is registered the
466
- [`RegisteredController `](https:// github.com/java-operator-sdk/java-operator-sdk/blob/ec37025a15046d8f409c77616110024bf32c3416/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/RegisteredController.java#L5-L5)
467
- is returned, which provides the related methods. These namespaces are meant to be changed when the operator is already
468
- running.
469
-
470
- In a real life scenario usually the list of the target namespaces configured in `ConfigMap ` or other input,
471
- this part however is out of the scope of the framework. So in case you want to use a `ConfigMap ` and react to change
472
- of it, registering an Informer and calling the `RegisteredController ` is up to the developer to implement.
463
+ A controller can be configured to watch a specific set of namespaces in addition of the
464
+ namespace in which it is currently deployed or the whole cluster. The framework supports
465
+ dynamically changing the list of these namespaces while the operator is running.
466
+ When a reconciler is registered, an instance of
467
+ [`RegisteredController `](https:// github.com/java-operator-sdk/java-operator-sdk/blob/ec37025a15046d8f409c77616110024bf32c3416/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/RegisteredController.java#L5)
468
+ is returned, providing access to the methods allowing users to change watched namespaces as the
469
+ operator is running.
470
+
471
+ A typical scenario would probably involve extracting the list of target namespaces from a
472
+ `ConfigMap ` or some other input but this part is out of the scope of the framework since this is
473
+ use-case specific. For example, reacting to changes to a `ConfigMap ` would probably involve
474
+ registering an associated `Informer ` and then calling the `changeNamespaces` method on
475
+ `RegisteredController `.
473
476
474
477
```java
475
478
@@ -485,9 +488,10 @@ of it, registering an Informer and calling the `RegisteredController` is up to t
485
488
486
489
```
487
490
488
- If a target namespaces change for a controller, it might be desirable to change the target namespaces of registered
489
- `InformerEventSource `- s. In order to express this , the InformerEventSource needs to be configured to
490
- `followControllerNamespaceChanges`, this the related method in `InformerConfiguration ` should return `true `:
491
+ If watched namespaces change for a controller, it might be desirable to propagate these changes to
492
+ `InformerEventSources ` associated with the controller. In order to express this ,
493
+ `InformerEventSource ` implementations interested in following such changes need to be
494
+ configured appropriately so that the `followControllerNamespaceChanges` method returns `true `:
491
495
492
496
```java
493
497
@@ -501,7 +505,7 @@ public class MyReconciler
501
505
502
506
InformerEventSource<ConfigMap , TestCustomResource > configMapES =
503
507
new InformerEventSource<> (InformerConfiguration . from(ConfigMap . class)
504
- .setAndFollowControllerNamespaceChanges (context)
508
+ .withNamespacesInheritedFromController (context)
505
509
.build(), context);
506
510
507
511
return EventSourceInitializer . nameEventSources(configMapES);
0 commit comments