Dennis-Mircea commented on code in PR #1237:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/1237#discussion_r4411152770
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/service/AbstractFlinkService.java:
##########
@@ -354,7 +355,11 @@ protected CancelResult cancelJob(
break;
}
}
- if (suspendMode.deleteCluster() || deleteCluster) {
+ // Without HA nothing records that the job has terminated, so a
restarted JobManager would
+ // submit the job again, ignoring the suspend savepoint.
+ if (suspendMode.deleteCluster()
+ || deleteCluster
+ ||
!HighAvailabilityMode.isHighAvailabilityModeActivated(conf)) {
Review Comment:
The SAVEPOINT suspend mode was not included here mainly because the returned
`savepointPath` of the stop-with-savepoint flow is still not saved and patched
into the status, so a cluster deletion combined with an operator restart will
make the job state to be entirely lost.
So, placing this check here is too early, and it might also miss some cancel
cases. The best will be to place at the end of the reconciliation cycle, under
`reconcileOtherChanges`.
##########
docs/content/docs/custom-resource/status-and-lifecycle.md:
##########
@@ -142,7 +142,7 @@ The lifecycle state is the summary and the fields above are
its inputs, so the v
| `DELETING` | Frozen at the last values | Frozen at the last
values | Frozen at the last values
|
| `DELETED` | Frozen at the last values | Frozen at the last
values | Frozen at the last values
|
-Three details sit outside the table. `DEPLOYED` and `STABLE` share the same
field values, what separates them is the reconciliation bookkeeping: the
resource is `STABLE` once `lastStableSpec` matches `lastReconciledSpec`.
`SUSPENDED` is recognized from the last reconciled spec, whose job state
records the suspension. And `FAILED` is reached on three paths: an error before
the first deployment, an observed `FAILED` job, or, for `FlinkDeployment`
resources, a lost or broken JobManager deployment whose `error` field reports
an unrecoverable condition.
+Three details sit outside the table. `DEPLOYED` and `STABLE` share the same
field values, what separates them is the reconciliation bookkeeping: the
resource is `STABLE` once `lastStableSpec` matches `lastReconciledSpec`.
`SUSPENDED` is recognized from the last reconciled spec, whose job state
records the suspension, and with high availability a suspend that stops the job
with a savepoint or a cancel, or finds it already stopped, keeps the JobManager
`READY` until `kubernetes.operator.jm-deployment.shutdown-ttl` runs out. And
`FAILED` is reached on three paths: an error before the first deployment, an
observed `FAILED` job, or, for `FlinkDeployment` resources, a lost or broken
JobManager deployment whose `error` field reports an unrecoverable condition.
Review Comment:
This should mention: `with high availability and in native mode ...`
--
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]
