afedulov commented on code in PR #637:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/637#discussion_r1273789422
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/observer/SnapshotObserver.java:
##########
@@ -74,8 +80,32 @@ public void observeSavepointStatus(FlinkResourceContext<CR>
ctx) {
cleanupSavepointHistory(ctx, savepointInfo);
}
+ public void observeCheckpointStatus(FlinkResourceContext<CR> ctx) {
+ if (!isCheckpointsTriggeringSupported(ctx.getObserveConfig())) {
+ return;
+ }
+ var resource = ctx.getResource();
+ var jobStatus = resource.getStatus().getJobStatus();
+ var checkpointInfo = jobStatus.getSavepointInfo();
+ var jobId = jobStatus.getJobId();
+
+ // If any manual or periodic savepoint is in progress, observe it
+ if (SnapshotUtils.checkpointInProgress(jobStatus)) {
+ observeTriggeredCheckpoint(ctx, jobId);
+ }
+
+ // REVIEW: clarify if this is relevant for checkpoints.
+ /*
+ // If job is in globally terminal state, observe last savepoint
+ if (ReconciliationUtils.isJobInTerminalState(resource.getStatus())) {
+ observeLatestCheckpoint(
+ ctx.getFlinkService(), checkpointInfo, jobId,
ctx.getObserveConfig());
+ }
+ */
Review Comment:
@gyfora there is something I do not quite get in the current logic: the
symmetric `observeLatestSavepoint` uses `getLastCheckpoint` that does not
explicitly make a distinction between savepoints and checkpoints. IIUC, if a
checkpoint is stored to an externally-addressable location, it will be
returned, pretending to be a Savepoint, and potentially used for recovery. Is
that desirable? I guess in this case we do not need to necessarily need to
introduce `observeLatestCheckpoint `.
--
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: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
