Hey Alyssa, Thanks for the response. I am not sure if `ProposedEpoch` is completely satisfying either. When the prevote flag is unset, the voters are expected to bump their own epoch when receiving the request. I think it makes the protocol a little simpler if the candidate epoch is always the current epoch of the candidate. That does mean we would have to tweak the acceptance criteria, but that seems a little better to keep the protocol clean. What do you think?
Thanks, Jason On Mon, Nov 27, 2023 at 2:57 PM Alyssa Huang <ahu...@confluent.io.invalid> wrote: > Thanks for the feedback Jason! > > 1. I might have missed it in the KIP, but could you clarify what happens > > when a pre-vote fails (i.e. a majority of voters reject the potential > > candidacy)? The transition descriptions only mention what happens if the > > prospective leader learns of a higher epoch. > > > I've updated the transition description for "Prospective" to cover this. > The behavior is also covered under "Proposed Changes" where I mention "When > a server receives VoteResponses, it will follow it up with another > VoteRequest with PreVote set to either true (send another Pre-Vote) or > false (send a standard vote)" - basically the server will send another > Pre-Vote request (after some backoff). > > 2. Do you think the pretend epoch bump is necessary? Would it be simpler to > > change the prevote acceptance check to assert a greater than or equal > > epoch? > > > > My thought process was that sending the "desired" next epoch would mean we > could borrow much of the `handleVoteRequest` logic for accepting/rejecting > Pre-Votes. The meaning of the `CandidateEpoch` field (I need to rename that > field, for now I'll call it "ProposedEpoch") would also remain pretty much > the same for both the Pre-Vote and standard vote case - "The bumped epoch > of the prospective/candidate sending the request". I do see how it could be > confusing that the Pre-Vote request includes a bumped epoch when in > actuality there is no epoch bump. I've changed the VoteRequest json a bit > in the KIP, let me know what you think. > > On Mon, Nov 27, 2023 at 1:40 PM Jason Gustafson <ja...@confluent.io.invalid > > > wrote: > > > Hey Alyssa, > > > > Thanks for the KIP! I have a couple questions: > > > > 1. I might have missed it in the KIP, but could you clarify what happens > > when a pre-vote fails (i.e. a majority of voters reject the potential > > candidacy)? The transition descriptions only mention what happens if the > > prospective leader learns of a higher epoch. > > 2. Do you think the pretend epoch bump is necessary? Would it be simpler > to > > change the prevote acceptance check to assert a greater than or equal > > epoch? > > > > Best, > > Jason > > > > > > On Wed, Nov 22, 2023 at 11:51 AM Alyssa Huang > <ahu...@confluent.io.invalid > > > > > wrote: > > > > > Hey folks, > > > > > > Starting a discussion thread for Pre-Vote design. Appreciate your > > comments > > > in advance! > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-996%3A+Pre-Vote > > > > > > Best, > > > Alyssa > > > > > >
