[
https://issues.apache.org/jira/browse/FLINK-30119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clara Xiong updated FLINK-30119:
--------------------------------
Summary: Breaking change: Flink Kubernetes Operator should store last
savepoint in the SavepointInfo.lastSavepoint field whether it is completed or
pending (was: Flink Kubernetes Operator should store last savepoint in the
SavepointInfo.lastSavepoint field whether it is completed or pending)
> Breaking change: Flink Kubernetes Operator should store last savepoint in the
> SavepointInfo.lastSavepoint field whether it is completed or pending
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FLINK-30119
> URL: https://issues.apache.org/jira/browse/FLINK-30119
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Reporter: Clara Xiong
> Assignee: Clara Xiong
> Priority: Major
>
> End user experience proposal:
> Users can see the properties of last savepoint pending or completed and can
> get status in one of three states for the status: PENDING, SUCCEEDED and
> FAILED. If there is never savepoint taken or attempted, it is empty.
> Completed savepoints (manual, periodic and upgrade) are included Savepoint
> history, merged with savepoints form Flink job.
> Users can see this savepoint with PENDING status once one is trigger. Once
> completed, users can see last savepoint status changed to SUCCEEDED and
> included in savepoint history, or FAILED and not in savepoint history. If
> there is other savepoint triggered after completion before user checks, user
> cannot see the status of the one they triggered but they can check if the
> savepoint is in the history.
> Currently lastSavepoint only stores the last completed one, duplicate with
> savepoint history. To expose the properties of the currently pending
> savepoint or last savepoint that failed, we need to expose those info in
> separate fields in SavepointInfo. The internal logic of Operator uses those
> fields for triggering and retries and creates compatibility issues with
> client. It also use more space for etcd size limit.
> Code change proposal:
> Use lastSavepoint to store the last completed/attempted one and deprecate
> SavepointInfo.triggerTimstamp, SavepointInfo.triggerType and
> SavepointInfo.formatType. This will simplify the CRD and logic.
> Add SavepointInfo::retrieveLastSavepoint method to return the last succeeded
> one.
> Update getLastSavepointStatus to simplify the logic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
