Hi Jose, Thanks for your response. I may have misunderstood the KIP while reading. Could you help clarify the following:
> The bootstrap checkpoint is loaded and decoded during node startup. It is a > fatal exception if the bootstrap checkpoint… This is one of the problems I am > trying to address with this KIP. chia_2: As far as I recall, it should be possible to start a node even if the bootstrap.checkpoint file does not exist (The MV will use latest production instead). Could you please share more details about the “fatal error” you mentioned during node startup? chia_3: If Kafka ≥ 4.2 creates bootstrap.checkpoint, users will see deprecation warnings when starting Kafka because the file exists, correct? Best, Chia-Ping On 2025/09/16 19:18:25 José Armando García Sancio wrote: > Hi Chia-Ping, > > Thanks for the feedback and questions. > > On Fri, Sep 12, 2025 at 9:47 PM Chia-Ping Tsai <[email protected]> wrote: > > 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? > > I don't think that Kafka should support this workflow. When > provisioning a cluster the user should use the same distribution for > formatting the cluster and for running the Kafka node. If the user > decides to downgrade the software version (JAR) in the middle of > provisioning, they should restart the provisioning process. > > This problem extends to other features of Kafka. For example, the user > can use Kafka >= 4.2 to write metadata records (e.g. finalized feature > version) that are not support by Kafka < 4.2. > > > chia_1: why we need to “deprecate” bootstrap checkpoint? > > Even though I don't think that we need to support the case you > highlighted above, I think that Kafka should support the user > upgrading the software version of existing clusters to >= 4.2 and then > downgrading the software version to Kafka < 4.2, as long as they > didn't upgrade the finalized feature versions to a value that is not > support by Kafka < 4.2. > > The issue with Kafka < 4.2 is that it assumes that the bootstrap > checkpoint always exist in the metadata log dir. The bootstrap > checkpoint is loaded and decoded during node startup. It is a fatal > exception if the bootstrap checkpoint. This is one of the problems I > am trying to address with this KIP. > > For existing clusters, we should only remove the bootstrap checkpoint in 5.x. > > > chia_2: Can we just get rid of it after writing the metadata record to zero > > checkpoint? > > Yes. The kafka storage format command will not create a bootstrap > checkpoint and will only create a zero checkpoint. This is okay > because I don't think we need to support users using one version of > kafka to format the metadata log dir and different version of kafka to > execute the node (controller or broker). > > What do you think? > -- > -José >
