Thanks Ismael. The vote passes after 12 days with the following +1s:
- Ryanne Dolan - Dongjin Lee - Randall Hauch (binding) - Tom Bentley (binding) - Gwen Shapira (binding) Thanks to all who voted and provided feedback. I'd also like to thank to Gregory Harris, who has been invaluable as an offline sounding board and has possibly contributed as much to this effort as the rest of the discussion thread combined. Thanks Greg! I'll update the KIP to the "Adopted" status and plan to have a feature-complete PR up for review by the end of the week. Cheers, Chris On Tue, Jun 15, 2021 at 11:17 AM Ismael Juma <ism...@juma.me.uk> wrote: > Chris updated the KIP to explain that this new Admin API behaves the same > as `Producer.initTransactions`, so that seems fine to me (i.e. I withdraw > my concern). I didn't review the whole KIP and since there are enough > votes, I'll leave it to you all. > > Ismael > > On Tue, Jun 15, 2021 at 5:59 AM Chris Egerton <chr...@confluent.io.invalid > > > wrote: > > > Hi Ismael, > > > > Friendly reminder that your comment is the only outstanding one. If I > don't > > hear back soon I'll probably close the KIP and we can address any > concerns > > in a follow-up KIP. > > > > Cheers, > > > > Chris > > > > On Thu, Jun 10, 2021 at 12:13 PM Chris Egerton <chr...@confluent.io> > > wrote: > > > > > Hi all, > > > > > > Firstly, thanks for the votes! > > > > > > Secondly--Ismael, in response to your feedback, I have to admit I'm a > > > little in the dark here. Are you suggesting that there be a new Kafka > API > > > for the act of fencing out a producer with a given transactional ID (or > > set > > > of transactional IDs)? If so, can you highlight the advantages of this > > new > > > API over the existing INIT_PRODUCER_ID API? At least as far as Connect > is > > > concerned, we likely wouldn't be able to fully leverage any > > > newly-introduced Kafka APIs in the release that they first appear, > since > > > we'd want to maintain compatibility with older broker versions. One > could > > > argue that since this feature is entirely opt-in we could make it a > > > requirement for users to upgrade their Kafka clusters to 3.0 (or > whatever > > > version supports this new API) in order to leverage it, but given the > > > effectiveness of the INIT_PRODUCER_ID API in servicing our needs, I'm > not > > > sure that would be the right tradeoff. And as far as the distinction > > > between client- and broker-side (or rather, transaction > coordinator-side) > > > logic goes, I'm having trouble envisioning anything--with or without a > > new > > > Kafka API--that would make the client-side logic simpler; the existing > > > proposal only involves a find coordinator request and then an init > > producer > > > request; is there a simpler way to handle things client-side that plays > > > nicely with established idioms for the admin and Kafka APIs? > > > > > > I plan to leave the vote thread open as long as there are unresolved > > > comments from serious contributors such as Ismael, and close it as soon > > as > > > those are all taken care of. > > > > > > Cheers, > > > > > > Chris > > > > > > On Thu, Jun 10, 2021 at 11:05 AM Ismael Juma <ism...@juma.me.uk> > wrote: > > > > > >> One concern I have is that we are not introducing a request for the > > >> fencing > > >> and implementing that logic in the admin client directly. I would > > prefer a > > >> request in the txn coordinator with the right semantics. > > >> > > >> Ismael > > >> > > >> On Thu, Jun 10, 2021, 7:46 AM Gwen Shapira <g...@confluent.io.invalid > > > > >> wrote: > > >> > > >> > I'm supportive of the feature and the interface details discussed in > > the > > >> > discussion thread. I just want to clarify that I'm voting for the > last > > >> > version discussed in the thread - that includes two phase upgrade > and > > no > > >> > breaking changes in 3.0. > > >> > > > >> > +1 (binding) > > >> > > > >> > > > >> > On Wed, Jun 9, 2021, 5:32 AM Chris Egerton > > <chr...@confluent.io.invalid > > >> > > > >> > wrote: > > >> > > > >> > > Hi all, > > >> > > > > >> > > Friendly reminder that the KIP freeze is today; please cast your > > >> votes if > > >> > > you'd like to see this feature introduced in time for 3.0. > > >> > > > > >> > > Cheers, > > >> > > > > >> > > Chris > > >> > > > > >> > > On Mon, Jun 7, 2021 at 1:49 AM Dongjin Lee <dong...@apache.org> > > >> wrote: > > >> > > > > >> > > > +1 (non-binding). > > >> > > > > > >> > > > Thanks, > > >> > > > Dongjin > > >> > > > > > >> > > > On Fri, Jun 4, 2021 at 2:35 PM Ryanne Dolan < > > ryannedo...@gmail.com> > > >> > > wrote: > > >> > > > > > >> > > > > +1 (non-binding) > > >> > > > > > > >> > > > > On Thu, Jun 3, 2021, 10:23 AM Chris Egerton > > >> > > <chr...@confluent.io.invalid > > >> > > > > > > >> > > > > wrote: > > >> > > > > > > >> > > > > > Hi all, > > >> > > > > > > > >> > > > > > I'd like to call for a vote on KIP-618, which adds support > for > > >> > > > > exactly-once > > >> > > > > > delivery guarantees for source connectors in the Kafka > Connect > > >> > > > framework. > > >> > > > > > > > >> > > > > > I suspect there might be a little more discussion to be had > > but > > >> > with > > >> > > > the > > >> > > > > > KIP freeze deadline approaching, I wanted to give anyone > > >> following > > >> > > > along > > >> > > > > > the chance to cast a +1 as soon as they feel that we've > gotten > > >> to a > > >> > > > > > reasonable state. > > >> > > > > > > > >> > > > > > The KIP: > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-618%3A+Exactly-Once+Support+for+Source+Connectors > > >> > > > > > > > >> > > > > > The discussion thread: > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > https://mail-archives.apache.org/mod_mbox/kafka-dev/202005.mbox/%3CCAMdOrUX-VK5OSB3OOdJNXW_YKEJH9FjQZ4eyzr2GXUhSeDnF3Q%40mail.gmail.com%3E > > >> > > > > > > > >> > > > > > Cheers, > > >> > > > > > > > >> > > > > > Chris > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > *Dongjin Lee* > > >> > > > > > >> > > > *A hitchhiker in the mathematical world.* > > >> > > > > > >> > > > > > >> > > > > > >> > > > *github: <http://goog_969573159/>github.com/dongjinleekr > > >> > > > <https://github.com/dongjinleekr>keybase: > > >> > > https://keybase.io/dongjinleekr > > >> > > > <https://keybase.io/dongjinleekr>linkedin: > > >> > > kr.linkedin.com/in/dongjinleekr > > >> > > > <https://kr.linkedin.com/in/dongjinleekr>speakerdeck: > > >> > > > speakerdeck.com/dongjin > > >> > > > <https://speakerdeck.com/dongjin>* > > >> > > > > > >> > > > > >> > > > >> > > > > > >
