gerkElznik commented on PR #1126: URL: https://github.com/apache/flink-kubernetes-operator/pull/1126#issuecomment-4938701283
Quick follow-up: two points in my comment above were from code tracing only, so I runtime-tested both in the same kind setup (webhook enabled via cert-manager, namespaced RBAC via `watchNamespaces`). - **Webhook + env var**: the webhook container does honor `WATCH_NAMESPACES` through the same config path. With the var on the operator container only (and no ConfigMap line), the webhook informers stayed cluster-scoped and the first `FlinkSessionJob` apply failed admission with `InternalError ... cannot list flinkdeployments at the cluster scope`. The informers are created lazily, so nothing fails at startup; it surfaces on the first session job. With the var on both containers, admission worked normally. So the follow-up would just need to set it on both. - **Dynamic namespaces**: with the env var unset and `kubernetes.operator.dynamic.namespaces.enabled: true`, a live ConfigMap edit rescoped all three controllers and the webhook informers with no restart. With the env var set, the same edit reloads the config (the log even prints the new namespace list) but the watch never changes and nothing warns about it; a FlinkDeployment created in the newly added namespace was never reconciled. So I'd want the precedence behavior to be a deliberate, documented call in the follow-up. Neither changes the options above; just confirming the details for whoever picks up the cleanup ticket. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
