Hey everyone, Starting a discussion about handling suspension behavior in FlinkBlueGreenDeployment. Currently, if you set spec.template.spec.job.state to suspended in the FlinkBlueGreenDeployment, it triggers a blue-green transition that creates a new suspended deployment - which then fails because the new 'green' pipeline never reaches running state. This creates a broken transition.
We're considering two options: *Option A*: Suspend child FlinkDeployments in place State changes to spec.template.spec.job.state trigger in-place suspension of the active child While suspended, all blue-green transitions are ignored until spec is set back to running Once running again, spins up new deployment with any accumulated spec changes and resumes normal blue-green operations *Option B*: Ignore state updates to child FlinkDeployment specs Simply ignores any spec.template.spec.job.state changes users attempt at the parent level Most minimal code change but completely prevents suspension from the blue-green level Tangential on whatever decision comes out of how we suspend blue-green deployments, would be worthwhile to consider if we have ‘suspended’ be a first class status / field in the top-level FlinkBlueGreenDeployment CR. We favour Option A which allows for a top-level method for suspending the FlinkBlueGreenDeployment pipeline, but would love to hear thoughts on which approach makes more sense or if there are other patterns that have been considered for ‘suspension’ in blue-green pipelines. Thanks, Daniel
