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 f8d85b0c [FLINK-29257] Clarify description of SAVEPOINT upgrade mode
f8d85b0c is described below
commit f8d85b0c654334b1892f246427f0b1ac2cdfa018
Author: Maximilian Michels <m...@apache.org>
AuthorDate: Mon Sep 19 18:06:01 2022 +0200
[FLINK-29257] Clarify description of SAVEPOINT upgrade mode
---
docs/content/docs/custom-resource/job-management.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/content/docs/custom-resource/job-management.md
b/docs/content/docs/custom-resource/job-management.md
index c81c3f9a..ba76b9ea 100644
--- a/docs/content/docs/custom-resource/job-management.md
+++ b/docs/content/docs/custom-resource/job-management.md
@@ -98,8 +98,8 @@ The `upgradeMode` setting controls both the stop and restore
mechanisms as detai
The three upgrade modes are intended to support different scenarios:
1. **stateless**: Stateless application upgrades from empty state
- 2. **last-state**: Quick upgrades in any application state (even for failing
jobs), does not require a healthy job as it always uses last checkpoint
information. Manual recovery may be necessary if HA metadata is lost.
- 3. **savepoint**: Use savepoint (when possible) for upgrade, providing
maximal safety and possibility to serve as backup/fork point.
+ 2. **last-state**: Quick upgrades in any application state (even for failing
jobs), does not require a healthy job as it always uses the latest checkpoint
information. Manual recovery may be necessary if HA metadata is lost.
+ 3. **savepoint**: Use savepoint for upgrade, providing maximal safety and
possibility to serve as backup/fork point. The savepoint will be created during
the upgrade process. Note that the Flink job needs to be running to allow the
savepoint to get created. If the job is in an unhealthy state, the last
checkpoint will be used (unless
`kubernetes.operator.job.upgrade.last-state-fallback.enabled` is set to
`false`). If the last checkpoint is not available, the job upgrade will fail.
During stateful upgrades there are always cases which might require user
intervention to preserve the consistency of the application. Please see the
[manual Recovery section](#manual-recovery) for details.
