This is an automated email from the ASF dual-hosted git repository.
gyfora pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/flink-kubernetes-operator.git
The following commit(s) were added to refs/heads/main by this push:
new b0adeede4 [FLINK-40365][docs] Correct savepoint config requirements
(#1173)
b0adeede4 is described below
commit b0adeede45a88c809a1a58c0e8dab0a891a2bb85
Author: Dale Lane <[email protected]>
AuthorDate: Fri Oct 30 13:57:08 2026 +0100
[FLINK-40365][docs] Correct savepoint config requirements (#1173)
---
docs/content.zh/docs/managing/job-management.md | 16 ++++++++--------
docs/content/docs/managing/job-management.md | 16 ++++++++--------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/docs/content.zh/docs/managing/job-management.md
b/docs/content.zh/docs/managing/job-management.md
index 0ded010b4..16f0f6dce 100644
--- a/docs/content.zh/docs/managing/job-management.md
+++ b/docs/content.zh/docs/managing/job-management.md
@@ -100,16 +100,16 @@ When a referenced Kubernetes resource changes, the
running job is not restarted
How state is carried across the restart is controlled through
`spec.job.upgradeMode`, with three supported values: `stateless`, `last-state`,
and `savepoint`. The setting controls both the stop and the restore mechanism,
as detailed in the following table:
-| | Stateless | Last State
| Savepoint |
-|------------------------|------------------|----------------------------------------|-------------------------------------------|
-| Config Requirement | None | Checkpointing Enabled
| Checkpoint or savepoint directory defined |
-| Job Status Requirement | None | Job or HA metadata accessible
| Job Running |
-| Suspend Mechanism | Cancel or delete | Cancel or delete (keeping HA
metadata) | Cancel with savepoint |
-| Restore Mechanism | Empty state | Use HA metadata or the latest
snapshot | Restore from savepoint |
-| Production Use | Not recommended | Recommended
| Recommended |
+| | Stateless | Last State
| Savepoint |
+|------------------------|------------------|----------------------------------------|--------------------------------------------|
+| Config Requirement | None | Checkpointing Enabled
| Checkpoint and savepoint directory defined |
+| Job Status Requirement | None | Job or HA metadata accessible
| Job Running |
+| Suspend Mechanism | Cancel or delete | Cancel or delete (keeping HA
metadata) | Cancel with savepoint |
+| Restore Mechanism | Empty state | Use HA metadata or the latest
snapshot | Restore from savepoint |
+| Production Use | Not recommended | Recommended
| Recommended |
{{< hint info >}}
-When HA is enabled the `savepoint` upgrade mode may fall back to the
`last-state` behavior in cases where the job is in an unhealthy state.
+When HA is enabled the `savepoint` upgrade mode may fall back to the
`last-state` behavior in cases where the job is in an unhealthy state,
restoring from the checkpoint directory. To prevent this, set
`kubernetes.operator.job.upgrade.last-state-fallback.enabled` to `false`. The
fallback still happens when `spec.flinkVersion` changes and the job can still
be cancelled.
{{< /hint >}}
With `FlinkStateSnapshot` resources enabled, the savepoint taken when
suspending in `savepoint` mode is tracked as its own snapshot resource, as
described under [Snapshot Management → Upgrade Triggering]({{< ref
"docs/managing/snapshot-management#upgrade-triggering" >}}). A `last-state`
upgrade creates no snapshot resource, it takes no new snapshot in the first
place, reusing the latest checkpoint instead.
diff --git a/docs/content/docs/managing/job-management.md
b/docs/content/docs/managing/job-management.md
index 0ded010b4..16f0f6dce 100644
--- a/docs/content/docs/managing/job-management.md
+++ b/docs/content/docs/managing/job-management.md
@@ -100,16 +100,16 @@ When a referenced Kubernetes resource changes, the
running job is not restarted
How state is carried across the restart is controlled through
`spec.job.upgradeMode`, with three supported values: `stateless`, `last-state`,
and `savepoint`. The setting controls both the stop and the restore mechanism,
as detailed in the following table:
-| | Stateless | Last State
| Savepoint |
-|------------------------|------------------|----------------------------------------|-------------------------------------------|
-| Config Requirement | None | Checkpointing Enabled
| Checkpoint or savepoint directory defined |
-| Job Status Requirement | None | Job or HA metadata accessible
| Job Running |
-| Suspend Mechanism | Cancel or delete | Cancel or delete (keeping HA
metadata) | Cancel with savepoint |
-| Restore Mechanism | Empty state | Use HA metadata or the latest
snapshot | Restore from savepoint |
-| Production Use | Not recommended | Recommended
| Recommended |
+| | Stateless | Last State
| Savepoint |
+|------------------------|------------------|----------------------------------------|--------------------------------------------|
+| Config Requirement | None | Checkpointing Enabled
| Checkpoint and savepoint directory defined |
+| Job Status Requirement | None | Job or HA metadata accessible
| Job Running |
+| Suspend Mechanism | Cancel or delete | Cancel or delete (keeping HA
metadata) | Cancel with savepoint |
+| Restore Mechanism | Empty state | Use HA metadata or the latest
snapshot | Restore from savepoint |
+| Production Use | Not recommended | Recommended
| Recommended |
{{< hint info >}}
-When HA is enabled the `savepoint` upgrade mode may fall back to the
`last-state` behavior in cases where the job is in an unhealthy state.
+When HA is enabled the `savepoint` upgrade mode may fall back to the
`last-state` behavior in cases where the job is in an unhealthy state,
restoring from the checkpoint directory. To prevent this, set
`kubernetes.operator.job.upgrade.last-state-fallback.enabled` to `false`. The
fallback still happens when `spec.flinkVersion` changes and the job can still
be cancelled.
{{< /hint >}}
With `FlinkStateSnapshot` resources enabled, the savepoint taken when
suspending in `savepoint` mode is tracked as its own snapshot resource, as
described under [Snapshot Management → Upgrade Triggering]({{< ref
"docs/managing/snapshot-management#upgrade-triggering" >}}). A `last-state`
upgrade creates no snapshot resource, it takes no new snapshot in the first
place, reusing the latest checkpoint instead.
