Hi, Jose, Thanks for the reply.
30. Who controls RPCs like Fetch, FetchSnapshot, DescribeQuorum RPC? They are shared between voters and observers. "The admin client will send the AddVoter and RemoveVoter requests if they are reported by ApiVersions." Does the client use supported ApiKeys or kraft.version feature in ApiVersions response for deciding whether to send AddVoter requests? Jun On Tue, Feb 27, 2024 at 8:20 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Hi Jun, > > Thanks for the comments. See my comments below. > > On Mon, Feb 26, 2024 at 4:48 PM Jun Rao <j...@confluent.io.invalid> wrote: > > 15.1 It would be useful to document the process of changing the > controller > > listener. For example, what configs need to be changed in what order and > > how a voter/observer selects the listener when multiple listeners are > > returned. > > Yes. I'll do that. I'll add a section to the "User Explanation" section. > > > 15.2 Thinking a bit more. The primary usage of multiple listeners is for > > changing the listeners online. So, we may not need to support multiple > > listeners in the initial setup phase. > > That is true. I'll revert those changes. We can create another KIP and > add them if there is a use case for supporting multiple endpoints > during bootstrapping. > > > 30. Well, VotersRecords and LeaderChangeRecord depend on RPCs like > > AddVoter, UpdateVoter and Vote, etc. Are those RPCs controlled by > > metadata.version? What happens if metadata.version doesn't enable those > > RPCs, but kraft.version requires them. > > Those RPCs and their versions are not controlled by the > metadata.version. They will be controlled by the ApiVersions reported > by the replicas and the kraft.version of the sender and receiver. > > For AddVoter and RemoveVoter, the receiving replica will return an > UNSUPPORTED_VERSION error if they receive a request and the > kraft.version is not greater than 1. The admin client will send the > AddVoter and RemoveVoter requests if they are reported by ApiVersions. > The receiver will return an UNSUPPORTED_VERSION if the kraft.version > is not greater than 1. Voters will send the AddVoter, RemoveVoter RPCs > if their local kraft.version is greater than 1 and the remote replica > supports those RPCs (through ApiVersions). > > Vote is a bit different. Since a replica's behavior is based on > uncommitted state it is possible for a voter in kraft.version 1 to > send a Vote request to a voter that is not in kraft.version 1. In that > case the receiving voter will handle the Vote request as normal but > not write the CandidateUuid that was sent in the request to the > QuorumStateData file. This is not ideal but I think it is okay since > this can only happen while the kraft.version is getting upgraded. > > UpdateVoter is also a bit different. Voters will always send this RPC > if the leader supports it through ApiVersion. Once the leader receives > the RPC it will persist the data sent to the log, if the kraft.version > is greater than 1. If the kraft.version is 0, the leader will handle > the RPC and store the information sent in memory but it will not > persist it to the log. > > This should be documented at different points in the KIP but I'll > create a section that summarizes this. > > Thanks! > -- > -José >
