On Tue, Jan 9, 2024, at 17:07, Jason Gustafson wrote: > Hi Jose, > > Thanks for the KIP! A few initial questions below: > > 1. In the user experience section, the user is expected to provide supply > the UUID for each voter. I'm assuming this is the directory.id coming from > KIP-858. I thought it was generated by the format comand automatically? It > seems like we will need a way to specify it explicitly.
Thanks for highlighting this, Jason. Leaving aside the bootstrapping paradox you just mentioned, I think it's extremely unfriendly to ask people to paste auto-generated directory IDs into the kafka-storage format command. We need a better solution for this -- one that doesn't require huge amounts of manual work for people setting up clusters. I think this is closely related to the problem of taking existing clusters (which effectively don't have directory IDs for controllers) and converting them to the new world. I think we can agree that a software upgrade process that requires manually configuring 3 UUIDs (or whatever) using painstaking manual commands on each controller node is a nonstarter. Overall, I do not think we should add any new flags to "kafka-storage.sh format". One approach might be to support both DIRID-less and DIRID-ful modes of operation of the quorum. Empty logs would be considered DIRID-less, and would remain so until the active controller decided to write out the record establishing the IDs. (And if the MV was low enough, it would just never do that). Given that we have to support DIRID-less mode anyway, this seems viable. > 2. Do we need the AddVoters and RemoveVoters control records? Perhaps the > VotersRecord is sufficient since changes to the voter set will be rare. Agreed. Voter changes should be extremely rare. Listing the full set makes debugging easier as well. > 4. Should ReplicaUuid in FetchRequest be a tagged field? It seems like a > lot of overhead for all consumer fetches. +1 best, Colin > > On Mon, Jan 8, 2024 at 10:13 AM José Armando García Sancio > <jsan...@confluent.io.invalid> wrote: > >> Hi all, >> >> KIP-853: KRaft Controller Membership Changes is ready for another >> round of discussion. >> >> There was a previous discussion thread at >> https://lists.apache.org/thread/zb5l1fsqw9vj25zkmtnrk6xm7q3dkm1v >> >> I have changed the KIP quite a bit since that discussion. The core >> idea is still the same. I changed some of the details to be consistent >> with some of the protocol changes to Kafka since the original KIP. I >> also added a section that better describes the feature's UX. >> >> KIP: https://cwiki.apache.org/confluence/x/nyH1D >> >> Thanks. Your feedback is greatly appreciated! >> -- >> -José >>
