history server
> like this for streaming jobs with the operator. Not really sure what you
> are trying to achieve with it , maybe some other audit feature would be
> enough to simply track the spec changes over time of the CR?
>
> Cheers,
> Gyula
>
>
> On Thu,
n operator main). I am actually working on adding a new
> way to perform the last-state upgrade via simple cancellation but that's a
> slightly orthogonal question.
>
> Long story short if you really need to integrate this with the history
> server, then you should switch to sa
Hi,
We are using Apache Flink Kubernetes operator to manage the deployment
lifecycle of our Flink jobs. And we are using the application mode with
"last-state" upgrade mode for each FlinkDeployment.
As I know, each FlinkDeployment will keep using the same job id across
different job deployments /
link-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/observer/SnapshotObserver.java#L74-L78
> )
> For session jobs you will not need sticky job ids because it's simply not
> relevant.
>
> Gyula
>
> On Tue, Apr 30, 2024 at 7:51 PM Alan Zhang wrote:
>
>
ble it should work fine.
>
> I am not aware of anyone working on this at the moment, it would be great
> if you could open a JIRA ticket to track this. If you are interested in
> working on this, we can also support you but this is a fairly complex
> feature that involves many layer
Hi,
We wanted to use the Apache Flink Kubernetes operator to manage the
lifecycle of our Flink jobs in Flink session clusters. And we wanted to
have the "last-state" upgrade feature for our use cases.
However, the latest official doc states the "last-state" upgrade mode is
not supported in the se
