Hey Jose, One additional thought. It would be helpful to have an example to justify the need for this:
> Wait for the fetch offset of the replica (ID, UUID) to catch up to the log end offset of the leader. It is helpful also to explain how this affects the AddVoter RPC. Do we wait indefinitely? Or do we give up and return a timeout error if the new voter cannot catch up? Probably the latter makes the most sense. Thanks, Jason On Tue, Jan 9, 2024 at 11:42 PM Colin McCabe <cmcc...@apache.org> wrote: > 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é > >> >
