Hi Jose Thanks for this beautiful KIP. The idea is cool to me.
chia_0: what happens if users uses post-KIP-1170 storage tool to create checkpoint with MV=4.1 and then run the Kafka with pre-KIP-1170 binary? chia_1: why we need to “deprecate” bootstrap checkpoint? Can we just get rid of it after writing the metadata record to zero checkpoint? Best, Chia-Ping > Jun Rao <j...@confluent.io.invalid> 於 2025年9月13日 清晨7:20 寫道： > > Hi, Jose, > > Thanks for the reply. > > JR2. The approach described sounds good to me. Could you include it in the > KIP? > > Jun > >> On Thu, Sep 4, 2025 at 12:17 PM José Armando García Sancio >> <jsan...@confluent.io.invalid> wrote: >> Hi Jun, thanks for the feedback. >>> On Thu, Aug 28, 2025 at 3:03 PM Jun Rao <j...@confluent.io.invalid> wrote: >>> JR1. "if the snapshot id has an epoch of 0 and a base offset of 0" : I >>> guess that snapshot here means checkpoint? >> Yes. I use the term interchangeably. I'll try to always use the word >> checkpoint instead of the word snapshot. I updated the KIP. >>> JR2. There seems to be an existing bootstrapping issue related to the >>> metadata version. KRaft client needs to issue ApiVersionRequest during >>> initialization. ApiVersionResponse needs to include the finalized >> metadata >>> version, which won't be available until KRaft client initializes and >>> bootstrapping completes. Currently, we just use MINIMUM_VERSION for >>> metadata in ApiVersionResponse during initialization, which is not >>> accurate. Should we address this issue here or a separate KIP. >> Good catch. Yes, we can try to address this issue in this KIP. The >> ApiVersions response schema and documentation says the following: >> Field: FinalizedFeaturesEpoch >> About: The monotonically increasing epoch for the finalized features >> information. Valid values are >= 0. A value of -1 is special and >> represents unknown epoch. >> Field: FinalizedFeatures >> About: List of cluster-wide finalized features. The information is >> valid only if FinalizedFeaturesEpoch >= 0. >> We can change the implementation for FinalizedFeatures so that it is >> empty if the HWM/FinalizedFeaturesEpoch is -1. In this case an unknown >> HWM means that the latest cluster metadata state is not known. We had >> a similar issue with the MV metrics and we used a similar fix in >> KIP-1180. >> To me this fix seems reasonable since the RPC schema already mentions >> that those values should be ignored. It is reasonable to assume that >> the only use of this field for display purposes. >> Thanks, >> -- >> -José
