gyfora commented on code in PR #365: URL: https://github.com/apache/flink-kubernetes-operator/pull/365#discussion_r974378675
########## 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 (if `kubernetes.operator.job.upgrade.last-state-fallback.enabled` is set to true). If the last checkpoint is not available, the job upgrade will fail. Review Comment: Technically it would be more precise to say: "unless `kubernetes.operator.job.upgrade.last-state-fallback.enabled` is set to false" because the default is true (you don't have to set it) -- 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]
