Dennis-Mircea opened a new pull request, #1224:
URL: https://github.com/apache/flink-kubernetes-operator/pull/1224
## What is the purpose of the change
The current PR introduces the following:
- Makes all operator-owned resources that manage executor thread pools
implement `AutoCloseable`, shutting down their thread pools on `close()`.
- Adds a shutdown hook to the operator that closes all owned `AutoCloseable`
resources.
- Makes the operator and webhook exit with status 1 if any error occurs
before the shutdown hook is registered / webhook creation.
## Brief change log
- `FlinkConfigManager`, `CanaryResourceManager`,
`FlinkResourceContextFactory`, `OperatorHealthService` and
`KubernetesOperatorMetricGroup` implement `AutoCloseable`. The metric group
also closes its `MetricRegistry`, which closes the reporters.
- `FlinkOperator.run()` registers a single shutdown hook calling
`FlinkOperator::stop`. It replaces the JOSDK hook and the separate health
service hook, so a JVM shutdown and a direct `stop()` call follow the same path.
- `FlinkOperator.stop()` closes the owned autoclosable components after
`operator.stop()`, so in-flight reconciliations drain first.
- `FlinkOperator.main` and `FlinkOperatorWebhook.main` log the startup
failure and call `System.exit(1)`, so the container fails immediately and shows
`Error` / `CrashLoopBackOff`. For the operator, the shutdown hook still runs
`stop()`.
- `InformerManager` implements `AutoCloseable` and stops its informers.
`FlinkOperatorWebhook` closes the Kubernetes client, informer manager and
config manager it creates when `run()` ends, in reverse creation order.
## Verifying this change
The current implementation can be verified by the existent tests that keep
passing + new tests added.
The implementation was manually verified on a local minikube as well:
- On operator startup failure (watched namespace without RBAC, so the
informer LIST gets 403): before, the JVM stayed up for 4m51s on the
`FlinkConfigManager` scheduler thread until the startup probe killed it. After,
the container exits with code 1 about 1 second after start, and the pod shows
`CrashLoopBackOff`.
- On webhook startup failure (invalid `WEBHOOK_SERVER_PORT`): the container
exits with code 1 about 1 second after start, logging `Failed to start the
webhook`.
- On SIGTERM signal: the shutdown completes in under a second, with no
warnings or exceptions.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changes to the `CustomResourceDescriptors`:
no
- Core observer or reconciler logic that is regularly executed: no
## Documentation
- Does this pull request introduce a new feature? no
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
<!--
If generative AI tooling has been used in the process of authoring this PR,
please
change the checkbox below to `[X]` followed by the name of the tool, and
uncomment the
"Generated-by" line. See the ASF Generative Tooling Guidance for details:
https://www.apache.org/legal/generative-tooling.html
You are responsible for the quality and correctness of every change in this
PR
regardless of the tooling used. Low-effort AI-generated PRs will be closed.
See
AGENTS.md for the full guidance.
-->
- [ ] Yes (please specify the tool below)
<!--
Generated-by: [Tool Name and Version]
-->
--
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]
