Thanks for answering my questions, Gyula! And your insights are very
helpful. Let me take a deeper look at the existing logic and think more.
On Tue, Apr 30, 2024 at 12:00 PM Gyula Fóra wrote:
> The application mode indeed has a sticky jobId (at least when we are
> performing a last-state upgrad
The application mode indeed has a sticky jobId (at least when we are
performing a last-state upgrade, otherwise a new jobId is generated during
stateless deployments). But that's only part of the story and arguably the
less important bit. The last-state upgrade mechanism for running/failing
(but ot
Hi Gyula,
Thanks for your reply! Good suggestion on JIRA ticket, I created a JIRA
ticket for tracking it: https://issues.apache.org/jira/browse/FLINK-35279.
We could be interested in working on it because of our own requirement, I
will check you and the community again once we have some updates.
Hi Alan!
I think it should be possible to address this gap for most cases. We don't
have the same robust way of getting the last-state information for session
jobs as we do for applications, so it will be slightly less reliable
overall.
For session jobs the last checkpoint info has to be queried f
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