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é
