Just to add. Even in your custom rollback mechanism in order to rollback
you can check the last validated spec field to get the proper image id.
On Sun, 27 Apr 2025 at 21:07, Alex Nitavsky wrote:
> Apriori your solution make sense.
> Just keep in mind that some form of blue green deployment can
Apriori your solution make sense.
Just keep in mind that some form of blue green deployment can be part of
the master soon.
On our side we rely on this experimental feature for a while, works fine.
Also it can probably make sense to consider to contribute or at least
request the change to ensure t
Hi Alex,
Thanks for the response!
Yes, we did consider the "Application upgrade rollbacks (Experimental)"
feature.
However, we decided not to use it mainly for two reasons:
1.
We wanted the flexibility to run our own custom verification logic after
deployment.
2.
The "experiment
Hey,
Did you consider to use the apache operator rollback feature? It can
probably cover the basic verification needs. Generally I would consider to
probably improve the apache operator rollback mechanism if it is not
sufficient.
If not it worth to check the blue green deployment of the operator
Hi Flink users,
We have a few Flink topologies running in production, managed by the Flink
Kubernetes Operator, and we typically deploy using ArgoCD.
Occasionally, we encounter bad deployments and need to roll back. When the
job state is not critical, we usually delete the state and restart the
F
