Hi everyone, I would like to start a discussion about FLINK-39243: Include observedGeneration for Suspended Flink Deployments [1].
Currently, there are two gaps in how the Flink Kubernetes Operator handles observedGeneration, which violates Kubernetes API conventions and breaks integration with standard deployment tools (e.g., Kapp) that rely on observedGeneration to determine whether a controller has processed a spec change: FlinkDeployment: When created with spec.job.state: suspended, the operator returns early without updating any status fields, observedGeneration, lastReconciledSpec, and lifecycleState all remain unset. FlinkBlueGreenDeployment: The status schema does not include an observedGeneration field at all, so deployment tools can never determine whether the controller has processed a given generation. The proposed changes are: For FlinkDeployment: acknowledge the suspended spec by setting status.observedGeneration, recording lastReconciledSpec with state SUSPENDED, and setting lifecycleState to SUSPENDED, without deploying any Flink resources. For FlinkBlueGreenDeployment: add an observedGeneration field to the status class and record lastReconciledSpec when blocking on a suspended initial state. Looking forward to your feedback on the approach! [1] https://issues.apache.org/jira/browse/FLINK-39243 Best Regards, Yanis Djeridi
