Hi Justine, Thanks for sharing your feedback! Here are some thoughts inlined below:
On Fri, Jul 8, 2022 at 11:33 AM Justine Olshan <jols...@confluent.io.invalid> wrote: > Hi David, > Thanks for sharing this KIP! Really exciting to hear how we are changing > the protocol! The motivation section really made me realize how useful this > change will be. > > I've done a first pass of the KIP, and may have more questions, but thought > I'd start with a few I thought of already. > > - I saw some usages of topic IDs in the new > protocols/records/interfaces, but wasn't sure if they were used > everywhere. > Are you planning on relying on topic IDs for the new protocol? > Yes we do plan to use topic IDs in the newly introduced RPC protocols (e.g. the new heartbeat req/resp), while keep the status quo for the existing protocols (e.g. the offset fetch / commit req/resp) that already encoded with topic names. > - I saw the section about using a feature flag first before integrating > the feature with ibp/metadata version. I understand the logic for > testing > with the flag, but it also seems like a bit of work to deprecate and > switch > to the ibp/metadata version approach. What was the reasoning behind > switching the enablement mechanism? > The main rationale is on the clients side, since such a behavioral change cannot be captured only by the apikey-version itself as the clients needs to behave differently with the new protocol even before they talk to the group coordinator. > - Generally, are there implications for KRaft here? (IBP/metadata > version is something that I think of) And if so, will both cluster > types be > supported? > Besides IBP / metadata, the only think I could think of is the group state machine snapshotting we may want to consider in the future with KRaft's extended snapshot capabilities (i.e. KIP-630). > > Thanks again to everyone who worked on this KIP! > Justine > > On Wed, Jul 6, 2022 at 1:45 AM David Jacot <dja...@confluent.io.invalid> > wrote: > > > Hi all, > > > > I would like to start a discussion thread on KIP-848: The Next > > Generation of the Consumer Rebalance Protocol. With this KIP, we aim > > to make the rebalance protocol (for consumers) more reliable, more > > scalable, easier to implement for clients, and easier to debug for > > operators. > > > > The KIP is here: https://cwiki.apache.org/confluence/x/HhD1D. > > > > Please take a look and let me know what you think. > > > > Best, > > David > > > > PS: I will be away from July 18th to August 8th. That gives you a bit > > of time to read and digest this long KIP. > > > -- -- Guozhang