Thanks, Luke. Feel free to ping me for reviews. I am happy to help on this one.
Cheers,
David
On Thu, Sep 22, 2022 at 11:00 AM Luke Chen wrote:
>
> Hi David,
>
> Sorry for the delay.
> I'll complete it in v3.4.0.
>
> Thank you.
> Luke
>
> On Thu, Sep 22, 2022 at 3:52 PM David Jacot
> wrote:
>
>
Hi David,
Sorry for the delay.
I'll complete it in v3.4.0.
Thank you.
Luke
On Thu, Sep 22, 2022 at 3:52 PM David Jacot
wrote:
> Hi Luke,
>
> Are you still interested in implementing this KIP? We need it for
> KIP-848. If you are not, we could find someone to take it over.
>
> Thanks,
> David
>
Hi Luke,
Are you still interested in implementing this KIP? We need it for
KIP-848. If you are not, we could find someone to take it over.
Thanks,
David
On Thu, Mar 3, 2022 at 10:04 AM Luke Chen wrote:
>
> Thanks, Ziming!
>
> So, now, this KIP vote passed with 3 binding +1 votes (David, Tom,
>
Thanks, Ziming!
So, now, this KIP vote passed with 3 binding +1 votes (David, Tom,
Guozhang) and 1 non-binding +1 vote (Ziming).
The vote will be closed.
Thanks again.
Luke
On Thu, Mar 3, 2022 at 5:00 PM deng ziming wrote:
> Thank you Luke for this work,
> I’m +1(non-binding)
>
> --
> Best,
>
Thank you Luke for this work,
I’m +1(non-binding)
--
Best,
Ziming Deng
> On Dec 1, 2021, at 8:36 AM, Luke Chen wrote:
>
> Hi all,
>
> I'd like to start the vote for KIP-792: Add "generation" field into
> consumer protocol.
>
> The goal of this KIP is to allow the assignor/consumer coordinator
Thanks David!
So, with 3 binding +1 votes (David, Tom, Guozhang), the vote passes.
Thanks everyone!
Luke
On Thu, Mar 3, 2022 at 4:34 PM David Jacot
wrote:
> +1 (binding). Thanks for the KIP!
>
> On Fri, Jan 28, 2022 at 6:13 PM Tom Bentley wrote:
> >
> > Hi Luke,
> >
> > Thanks for the KIP, +
+1 (binding). Thanks for the KIP!
On Fri, Jan 28, 2022 at 6:13 PM Tom Bentley wrote:
>
> Hi Luke,
>
> Thanks for the KIP, +1 (binding).
>
> Kind regards,
>
> Tom
>
> On Wed, 19 Jan 2022 at 13:16, Luke Chen wrote:
>
> > Hi all,
> >
> > Bump this thread to see if there are other comments to this K
Hi Luke,
Thanks for the KIP, +1 (binding).
Kind regards,
Tom
On Wed, 19 Jan 2022 at 13:16, Luke Chen wrote:
> Hi all,
>
> Bump this thread to see if there are other comments to this KIP.
> So far, I have one +1 vote (binding), and need more votes.
>
> Thank you.
> Luke
>
> On Tue, Dec 21, 202
Hi all,
Bump this thread to see if there are other comments to this KIP.
So far, I have one +1 vote (binding), and need more votes.
Thank you.
Luke
On Tue, Dec 21, 2021 at 10:33 AM Luke Chen wrote:
> Hi all,
>
> Bump this thread to see if there are other comments to this KIP.
>
> Thank you.
>
Hi all,
Bump this thread to see if there are other comments to this KIP.
Thank you.
Luke
On Fri, Dec 17, 2021 at 1:27 AM Colin McCabe wrote:
> Thanks for the explanation, Luke. That makes sense.
>
> best,
> Colin
>
> On Thu, Dec 9, 2021, at 13:31, Guozhang Wang wrote:
> > Thanks Luke, in that
Thanks for the explanation, Luke. That makes sense.
best,
Colin
On Thu, Dec 9, 2021, at 13:31, Guozhang Wang wrote:
> Thanks Luke, in that case I'm +1 on this KIP.
>
> On Thu, Dec 9, 2021 at 1:46 AM Luke Chen wrote:
>
>> Hi Guozhang,
>>
>> Thanks for your comment.
>>
>> > we need to make sure th
Thanks Luke, in that case I'm +1 on this KIP.
On Thu, Dec 9, 2021 at 1:46 AM Luke Chen wrote:
> Hi Guozhang,
>
> Thanks for your comment.
>
> > we need to make sure the old-versioned leader would be able to ignore the
> new
> field during an upgrade e.g. without crashing.
>
> Yes, I understand.
Hi Guozhang,
Thanks for your comment.
> we need to make sure the old-versioned leader would be able to ignore the
new
field during an upgrade e.g. without crashing.
Yes, I understand. I'll be careful to make sure it won't crash the old
versioned leader.
But basically, it won't, because we append
Hi Luke,
Thanks for the KIP.
One thing I'd like to double check is that, since the
ConsumerProtocolSubscription is not auto generated from the json file, we
need to make sure the old-versioned leader would be able to ignore the new
field during an upgrade e.g. without crashing. Other than that, t
Hi Colin,
I'm not quite sure if I understand your thoughts correctly.
If I was wrong, please let me know.
Also, I'm not quite sure how I could lock this feature to a new IBP
version.
I saw "KIP-584: Versioning scheme for features" is still under development.
Not sure if I need to lock the IBP ver
Hi Colin,
Thanks for your comments. I've updated the KIP to mention about the KIP
won't affect current broker side behavior.
> One scenario that we need to consider is what happens during a rolling
upgrade. If the coordinator moves back and forth between brokers with
different IBPs, it seems that
Hi Luke,
Thanks for the explanation.
I don't see any description of how the broker decides to use the new version of
ConsumerProtocolSubscription or not. This probably needs to be locked to a new
IBP version.
One scenario that we need to consider is what happens during a rolling upgrade.
If t
Hi Colin,
Thanks for your comment.
> How are we going to avoid the situation where the broker restarts, and
the same generation number is reused?
Actually, this KIP doesn't have anything to do with the brokers. The
"generation" field I added, is in the subscription metadata, which will not
be des
How are we going to avoid the situation where the broker restarts, and the same
generation number is reused?
best,
Colin
On Tue, Nov 30, 2021, at 16:36, Luke Chen wrote:
> Hi all,
>
> I'd like to start the vote for KIP-792: Add "generation" field into
> consumer protocol.
>
> The goal of this KI
Hi all,
I'd like to start the vote for KIP-792: Add "generation" field into
consumer protocol.
The goal of this KIP is to allow the assignor/consumer coordinator to have
a way to identify the out-of-date members/assignments, to avoid rebalance
stuck issues in current protocol.
Detailed descripti
20 matches
Mail list logo
