Hi Jun, Thank you for having another look.
11. That is correct. I have updated the KIP in an attempt to make this clearer. I think the goal should be to try to minimize the chance that a log directory may happen while the metadata is incorrect about the log directory assignment, but also have a fallback safety mechanism to indicate to the controller that some replica was missed in case of a bad race. 13. Ok, I think I have misunderstood this. Thank you for correcting me. In this case the broker can update the existing meta.properties and create new meta.properties in the new log directories. This also means that the update-directories subcommand in kafka-storage.sh is not necessary. I have updated the KIP to reflect this. Please have another look. Thank you, -- Igor > On 22 Dec 2022, at 00:25, Jun Rao <j...@confluent.io.INVALID> wrote: > > Hi, Igor, > > Thanks for the reply. > > 11. Yes, your proposal could work. Once the broker receives confirmation of > the metadata change, I guess it needs to briefly block appends to the old > replica, make sure the future log fully catches up and then make the switch? > > 13 (b). The kafka-storage.sh is only required in KIP-631 for a brand new > KRaft cluster. If the cluster already exists and one just wants to add a > log dir, it seems inconvenient to have to run the kafka-storage.sh tool > again. > > Thanks, > > Jun
