Hi Gyula! Great to hear from you, and thanks for your feedback.
I like your alternative approach. I'm curious what you are thinking regarding one-shot configs/settings - is there a common use-case you have in mind? Luca On Sat, Aug 8, 2026 at 2:47 AM Gyula Fóra <[email protected]> wrote: > Hey Luca! > > I have thought about this a few times as well that it may be better to > make an operation like this. > > I don't really like the idea of having multiple distinct nonces for > overlapping operations (savepointRedeployNonce, statelessRedeployNonce etc.) > > An alternative approach could be if we want to make one-shot > deployment operations more flexible is to introduce a new spec object field > such as: > > ```yaml > spec: > job: > redeploy: > nonce: x -> y // The main trigger > state: null / initial state reference > // Other future additions such as one-shot configs/settings etc. > ``` > > What do you think? > Gyula > > > On Fri, Aug 7, 2026 at 9:28 PM Luca Castelli via dev <[email protected]> > wrote: > >> Hi all, >> >> I would like to get feedback on adding a statelessRestartNonce to the >> Flink >> Kubernetes Operator. >> >> Today, if a job normally uses upgradeMode: savepoint or last-state, >> triggering a fresh restart currently requires: >> >> 1. Changing upgradeMode to stateless >> 2. Bumping restartNonce >> 3. Changing upgradeMode back afterward >> >> This temporarily mixes an operational action with the job's steady-state >> recovery policy. Users sometimes forget the third step, leaving >> subsequent upgrades (deploys or scaling events) stateless and creating a >> risk of state loss. >> >> Would the community be open to this approach? >> >> ```yaml >> spec: >> job: >> statelessRestartNonce: 42 >> ``` >> >> Alternatively, we could name it statelessRedeployNonce. >> >> Thanks, >> Luca >> >
