Hi all, Given the importance of this KIP, we want to keep the vote open for a few more days to give time to people who had comments in the DISCUSS thread to cast their vote if they want.
On Wed, Feb 25, 2026 at 10:47 AM Josep Prat via dev <[email protected]> wrote: > Hi all, > As a co-author of the KIP, I want to explicitly cast my vote for this KIP. > > +1 (binding) > > > On Wed, Feb 25, 2026 at 9:02 AM Luke Chen <[email protected]> wrote: > > > I've re-read KIP-1150, and still agree this is what we need for Apache > > Kafka. > > > > +1 (binding) from me. > > > > Thank you, > > Luke > > > > On Wed, Feb 25, 2026 at 12:10 PM Chris Egerton <[email protected]> > > wrote: > > > >> Hi all, > >> > >> Thanks for the KIP. I've reviewed 1150, 1163, and 1164, as well as the > >> relevant discussion threads. I may have granular comments about 1163 and > >> 1164 but the overall approach suggested in 1150 looks good to me. I > >> especially like that the approach covers two main pain points of > operating > >> and paying for Kafka today: it allows cross-AZ traffic to be reduced > (even > >> eliminated in some cases), and it also allows local disk usage by > brokers > >> to be reduced (if operators opt for a small local cache on follower > >> brokers > >> for non-tiered segments). > >> > >> +1 (binding) > >> > >> Cheers, > >> > >> Chris > >> > >> On Mon, Jan 26, 2026 at 3:36 PM vaquar khan <[email protected]> > >> wrote: > >> > >> > Hi Josep, > >> > > >> > Thank you for the detailed response. I appreciate the clarification > >> > regarding the distinction between the Inkless POC and the KIP design. > >> > > >> > However, my objection is not based on temporary bugs in the fork, but > >> *on > >> > architectural gaps in the KIPs themselves* that these implementation > >> issues > >> > highlighted. If we are voting to approve the design, the design > >> documents > >> > must be structurally complete regarding data safety. > >> > > >> > *1. Regarding Storage Leaks (The Missing Design)* You mentioned that > >> > cleanup logic "can be defined later." However, KIP-1163 explicitly > >> > delegates this responsibility to a separate process, and KIP-1165 > >> (Object > >> > Compaction/GC) is currently marked as "Discarded" in the wiki. > >> > > >> > We cannot vote to approve a storage engine that has no specified > >> mechanism > >> > for garbage collection. The "Upload-then-Commit" pattern described in > >> > KIP-1163 structurally creates orphaned segments during broker > failures. > >> > Without an active KIP defining the reconciliation protocol (since > >> KIP-1165 > >> > was withdrawn), the proposal effectively describes a system with > >> unbounded > >> > storage growth during failure modes. This is a blocking design gap, > not > >> an > >> > implementation detail. > >> > > >> > *2. Regarding EOS (The Coordinator Synchronization Gap)* This is not a > >> > misunderstanding of standard Kafka transactions; it is a critique of > how > >> > KIP-1150 changes them. Standard EOS relies on the Partition Leader to > >> > sequence markers and calculate the LSO (Last Stable Offset) in memory. > >> > KIP-1150 removes the Leader. > >> > > >> > KIP-1164 (Batch Coordinator) must explicitly define the RPC flow > between > >> > the Transaction Coordinator and the Batch Coordinator to replace the > >> > leader's role. Currently, the KIP does not specify how the system > >> prevents > >> > a "Split Brain" scenario where a consumer reads ahead of a transaction > >> > marker that hasn't yet been sequenced by the Batch Coordinator. This > is > >> a > >> > protocol-level correctness issue that must be resolved in the text > >> before > >> > adoption. > >> > > >> > Please note - I am maintaining my objection based on missing > >> > specifications, not code bugs. > >> > > >> > I respectfully request that we pause the vote until: > >> > > >> > A valid design for Garbage Collection (replacing the discarded > >> > KIP-1165) is added to the proposal. > >> > > >> > The Transaction/LSO synchronization protocol is explicitly > >> documented > >> > in KIP-1164. > >> > > >> > Regards, > >> > > >> > Vaquar Khan > >> > Sr Data Architect > >> > https://www.linkedin.com/in/vaquar-khan-b695577/ > >> > > >> > > > > -- > [image: Aiven] <https://www.aiven.io> > > *Josep Prat* > Sr. Engineering Director, Streaming Services, *Aiven* > [email protected] | +491715557497 > aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud > > > <https://www.linkedin.com/company/aiven/> < > https://twitter.com/aiven_io> > *Aiven Deutschland GmbH* > Alexanderufer 3-7, 10117 Berlin > > Geschäftsführer: Oskari Saarenmaa, Kenneth Chen > Amtsgericht Charlottenburg, HRB 209739 B > -- Anatolii Popov Senior Software Developer, *Aiven OY* m: +358505126242 w: aiven.io e: [email protected] <https://www.facebook.com/aivencloud> <https://www.linkedin.com/company/aiven/> <https://twitter.com/aiven_io>
