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
