[
https://issues.apache.org/jira/browse/FLINK-30119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642162#comment-17642162
]
Clara Xiong commented on FLINK-30119:
-------------------------------------
Updating the title to reflect the fact this could break existing application
relying on some fields of SavepointInfo although there is potential benefits to
simplying logic and reduce the size of etcd object which is hitting upper limit.
> 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)
