Hi Daren, The behavior is consistent with the regular FlinkDeployment where the cleanup will also cancel any running jobs. Are you intending to recover jobs from another session cluster?
-Max On Mon, Jul 17, 2023 at 4:48 PM Wong, Daren <daren...@amazon.co.uk.invalid> wrote: > > Hi devs, > > I would like to enquire about the cleanup procedure upon FlinkSessionJob > deletion. Currently, FlinkSessionJobController would trigger a cleanup in the > SessionJobReconciler which in turn cancels the Flink Job. > > Link to code: > https://github.com/apache/flink-kubernetes-operator/blob/371a2e6bbb8008c8ffccfff8fc338fb39bda19e2/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/sessionjob/SessionJobReconciler.java#L110 > > This make sense to me as we want to ensure the Flink Job is ended gracefully > when the FlinkSessionJob associated with it is deleted. Otherwise, the Flink > Job will be “leaked” in the Flink cluster without a FlinkSessionJob > associated to it for the Kubernetes Operator to control. > > That being said, I was wondering if we should consider for scenarios where > users may not want FlinkSessionJob deletion to create a side-effect such as > cancelJob? For example, the user just wants to simply delete the whole > namespace. One way of achieving this could be to put the job in SUSPENDED > state instead of cancelling the job. > > I am opening this discussion thread to get feedback and input on whether this > alternative cleanup procedure is worth considering and if anyone else see any > potential use case/benefits/downsides with it? > > Thank you very much. > > Regards, > Daren
