Hi Daniel, Thanks, just upon a quick read I’d be leaning towards Option A since it sounds more intuitive. I’ll give it a bit more thought too in case there’s a a corner case escaping us. Also interested in what others think.
- Sergio > On Jan 6, 2026, at 11:10 AM, Daniel Rossos via dev <[email protected]> > wrote: > > 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
