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é
