Hi, Jose, Thanks for the reply.
15. VotersRecord: Ok. I got the need for including the listener name in the endpoint. Currently, controller.quorum.voters can only specify one endpoint per voter. So, we can only support one listener. It's fine if we want to extend that in this KIP. 15.1 "In this configuration, the local replica needs to use CONTROLLER_PLAINTEXT because that is what is supported by all of the voters." Hmm, my understanding is that what listener to use can be made pairwise between the sender and the receiver. There is no need to pick the same listener across all voters, right? 15.2 When bootstrapping with just one controller, we could register a single voter with multiple listeners from controller.listener.names and listeners. However, when bootstrapping with multiple controllers, kafka-storage only has the option to specify one listener (--controller-quorum-voters <replica-id>-<replica-uuid>@<host>:<port>) per voter. Should we make them consistent? 18.3 : "It will not use the metadata layer (QuorumController) to update and persist the finalized kraft.version." So, we depend on KRaftVersionRecord to propagate finalized kraft.version to brokers/controllers? It would be useful to document that. 27. "My plan is to rely on KIP-996: Pre-vote:". Hmm, Diego's paper says "Unfortunately, the Pre-Vote phase does not solve the problem of disruptive servers". Is that a real issue? 30. So, VotersRecords and LeaderChangeRecord are controlled by both kraft.version and metadata.version? How do we resolve conflicts? For example, if a user downgrades kraft.version, do we automatically downgrade metadata.version to the matching level? 31. kafka-features now has --release-software. Could we change kafka-storage to be consistent? Currently, kafka-storage takes --release-version. 32. Now that we have more than one feature, should we extend kafka-storage to also support --feature FEATURE like kafka-features? Jun On Fri, Feb 23, 2024 at 12:00 PM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Jun, I updated one of the rejected ideas to better explain why KRaft > can't rely on information stored by the metadata layer. > > Thanks, > -- > -José >
