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
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
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
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
