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
>
