Hi, Jose, Thanks for the reply.
30. Historically, we used MV to gate the version of Fetch request. Are you saying that voters will ignore MV and only depend on raft.version when choosing the version of Fetch request? 35. Upgrading the controller listeners. 35.1 So, the protocol is that each controller will pick the first listener in controller.listener.names to initiate a connection? 35.2 Should we include the new listeners in the section "Change the controller listener in the brokers"? 35.3 For every RPC that returns the controller leader, do we need to return multiple endpoints? 35.4 The controller/observer can now get the endpoint from both records and RPCs. Which one takes precedence? For example, suppose that a voter is down for a while. It's started and gets the latest listener for the leader from the initial fetch response. When fetching the records, it could see an outdated listener. If it picks up this listener, it may not be able to connect to the leader. 36. Bootstrapping with multiple voters: How does a user get the replica uuid? In that case, do we use the specified replica uuid instead of a randomly generated one in the meta.properties file in metadata.log.dir? Jun On Fri, Mar 1, 2024 at 10:51 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Hi Jun, > > Thanks for the feedback. See my comments below. > > On Tue, Feb 27, 2024 at 11:27 AM Jun Rao <j...@confluent.io.invalid> wrote: > > 30. Who controls RPCs like Fetch, FetchSnapshot, DescribeQuorum RPC? They > > are shared between voters and observers. > > For Fetch and FetchSnapshot, this KIP adds the tagged field > ReplicaUuid to the request. This means that if the sender supports the > latest version it can always add the replica uuid to the request. If > the receiver supports the new tagged field it is included in the > appropriate FetchRequestData and FetchSnapshotRequestData field. If it > doesn't support the new tagged field it will be in the unknown tagged > fields. > > For DescribeQuorum, this KIP only changes the response. The KRaft > leader will inspect the RequestHeader::apiVersion to determine what > information to include in the response. > > > Does the client use supported ApiKeys or kraft.version feature in > > ApiVersions response for deciding whether to send AddVoter requests? > > That's a good point. The Admin client has access to the finalized > kraft.version in the ApiVersions response. I was thinking of only > using the ApiKeys since we don't have a precedence of using the > finalized features in the Admin client. The receiver of the request > still needs to validate the kraft.version for those requests and > return an UNSUPPORTED_VERSION error in those cases. > > Do you mind if we define this in a separate KIP? > > Thanks, > -- > -José >
