Hi Rajini,
Thank you for the KIP. Overall, it looks good to me. I have few
questions/suggestions:
1. It is hard to grasp what `Action#count` is for. I guess I understand
where you want to go with it but it took me a while to figure it out.
Perhaps, we could come up with a better name than `count`
ag`. It is provided to improve
> audit logging in the authorizer. The enum values have javadoc which
> indicate how the authorization result is used in each of the modes to
> enable authorizers to log audit messages at the right severity level.
>
> Regards,
>
> Rajini
>
> On
Hi Colin,
Thank you for the KIP! Things are well explained!. It is huge improvement
for the Kafka protocol. I have few comments on the proposal:
1. The interleaved tag/length header sounds like a great optimisation as it
would be shorter on average. The downside, as
you already pointed out, is th
+1 (non-binding)
Thanks for the KIP! Simple yet very useful.
Best,
David
On Wed, Aug 14, 2019 at 9:24 AM Robert Barrett
wrote:
> +1 (non-binding)
>
> This will be good to have, thanks David!
>
> Bob
>
> On Wed, Aug 14, 2019 at 6:08 AM Mickael Maison
> wrote:
>
> > +1 non binding
> > Thank you
Hi Kafka team,
First of all, thank you for the awesome work! Kafka is really an awesome
piece of technology. I have been using it since you open sourced it and
would like to contribute to it.
Could you please add me to the contributor list?
Thanks!
David Jacot
nging
> > > the protocol on the wire.
> > >
> > > Can an Optional field have a struct type which internally contains an
> array
> > > field at any level?
> > >
> > > Thanks,
> > > Satish.
> > >
> > >
> > >
+1 (non-binding)
Thanks for the KIP, Rajini.
Best,
David
On Sun, Aug 18, 2019 at 9:42 PM Mickael Maison
wrote:
> +1 (non binding)
> Thanks for the KIP!
>
> On Sun, Aug 18, 2019 at 3:05 PM Ron Dagostino wrote:
> >
> > +1 (non-binding)
> >
> > Thanks, Rajini.
> >
> > Ron
> >
> > On Sat, Aug 17,
Hey,
I would like to create a KIP but I don't have the permission yet. Could
someone grant me the relevant permission to the wiki?
Thanks,
David
Hi Bill,
Sure. It is dajac.
Thanks,
David
On Tue, Aug 20, 2019 at 3:55 PM Bill Bejeck wrote:
> Hi David,
>
> Sure thing, can you share your wiki username?
>
> Thanks,
> Bill
>
> On Tue, Aug 20, 2019 at 9:53 AM David Jacot wrote:
>
> > Hey,
> >
>
Thank you, Bill!
Le mar. 20 août 2019 à 16:45, Bill Bejeck a écrit :
> Hi David,
>
> You're all set now.
>
> -Bill
>
> On Tue, Aug 20, 2019 at 10:04 AM David Jacot wrote:
>
> > Hi Bill,
> >
> > Sure. It is dajac.
> >
> > Thanks,
&g
+1 (non-binding)
Thanks for the KIP!
Best,
David
On Tue, Aug 20, 2019 at 7:55 PM Jason Gustafson wrote:
> Hi All,
>
> I'd like to start a vote on KIP-352, which is a follow-up to KIP-455 to fix
> a long-known shortcoming of URP reporting and to improve reassignment
> monitoring:
>
> https://cw
Hello,
It would be better to ask such question on the user mailing list.
The reason is that the group is created automatically when a consumer
joins it. It is not created explicitly so it can be restricted.
In your case, you could setup a ACL to authorize the application to only
use the group yo
Hi all,
I would like to start a discussion for KIP-511:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-511%3A+Collect+and+Expose+Client%27s+Name+and+Version+in+the+Brokers
Let me know what you think.
Best,
David
-version?
>
> 1.
> https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaRequestHandler.scala#L231
>
> Thanks,
> Satish.
>
>
>
>
> On Wed, Aug 21, 2019 at 5:33 PM David Jacot wrote:
> >
> > Hi all,
> >
> > I would lik
lin
> >
> >
> > On Wed, Aug 21, 2019, at 12:05, Adam Bellemare wrote:
> > > +users mailing list
> > >
> > > David,
> > >
> > > I don't think I really understand your email. Are you saying that this
> > can
> > > alread
broker name and version to the
> > ApiVersionResponse?
> > While an application must not use this information to detect features (Hi
> > Jay!), it is good for troubleshooting
> > and providing more meaningful logs to the client user in case a feature
> > (based on
:31 AM David Jacot wrote:
> Hi Magnus,
>
> Thank you for your feedback. Please, find my comments below.
>
> 1. I thought that the clientId was meant for this purpose (providing
> information about the application). Is there a gap I don't see?
>
> 2. I have put two f
+1 (non-binding)
Thank for the KIP. Great addition to the Kafka protocol!
Best,
David
Le mar. 3 sept. 2019 à 19:17, Colin McCabe a écrit :
> Hi all,
>
> I'd like to start the vote for KIP-482: The Kafka Protocol should Support
> Optional Tagged Fields.
>
> KIP:
> https://cwiki.apache.org/confl
Request, it
> doesn't make sense to fall back all the way to 0 if the broker supports 1
> (for example).
>
> If you agree, it would be good to spell this out in the KIP, so that if we
> want to add more things to the response, we can, without losing them each
> time the c
Hi all,
While implementing the KIP, I have realized that a new error code and
exception is required to notify the caller that offsets of a topic can not
be deleted because the group is actively subscribed to the topic.
I would like to know if there are any concerns with these changes before
updat
Hi Manikumar,
Could we add KIP-511 to the plan? I think it will make it.
Thanks,
David
On Tue, Aug 27, 2019 at 5:32 PM Manikumar wrote:
> Hi all,
>
> I put together a draft release plan with Oct 2019 as the release month and
> a list of KIPs that have already been voted:
>
> https://cwiki.apac
n evolve the
> request header by adding tagged fields...
> >
> > Another option is to fall all the way back to version 0 when the broker
> doesn't understand the client's supplied version. Version 0 had no content
> in the request at all, so there is no need for the b
in the request at all, so there is no need for the broker to know exactly
> how long the supplied request header is. (This assumes that the first 4
> fields of the request header will never change, which seems like a
> reasonable assumption...)
> >
> > best,
> > C
r
> don't set the version at all (for compatibility). So the version/type has
> to be mutable and added after the TCP connection itself is established.
>
> best,
> Colin
>
>
> On Mon, Sep 9, 2019, at 06:11, David Jacot wrote:
> > Hi Gwen,
> >
> > The
Hey,
I have done this before with this proxy:
https://github.com/grepplabs/kafka-proxy#connect-to-kafka-through-socks5-proxy-example
You can spin up a socks proxy when you ssh to your jumphost (-D argument if
not mistaken) and
configure the proxy as described in the readme.
It is good for dev an
+1 (non-binding)
Le jeu. 12 sept. 2019 à 20:35, Gwen Shapira a écrit :
> +1 (binding)
>
> On Mon, Sep 9, 2019 at 8:28 AM Colin McCabe wrote:
> >
> > Hi all,
> >
> > I'd like to start the vote for KIP-500: Replace ZooKeeper with a
> Self-Managed Metadata Quorum.
> >
> > The DISCUSS thread from t
rsions": "0+",
"about": "The responses for each partition in the topic.",
"fields": [
{ "name": "PartitionIndex", "type": "int32", "versions": "0+",
"mapKey": true,
Hi all,
I would like to start a vote on KIP-511:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-511%3A+Collect+and+Expose+Client%27s+Name+and+Version+in+the+Brokers
Best,
David
Hi all,
I have updated the KIP to reflect the offline discussion that we have had.
It seems that we have finally
reached a consensus on the approach. Therefore, I will start a vote.
Best,
David
On Wed, Sep 11, 2019 at 3:53 PM David Jacot wrote:
> Hi all,
>
> I have discussed wi
Hey Jose,
Yes, we have considered it. Check "Put clientName and clientVersion in the
RequestHeader" in the rejected alternatives.
Best,
David
On Tue, Sep 17, 2019 at 12:57 AM Jose Armando Garcia Sancio <
jsan...@confluent.io> wrote:
> On Mon, Sep 9, 2019 at 4:00 PM Colin McCabe wrote:
>
> >
>
.
What do you think?
Best,
David
On Fri, Sep 13, 2019 at 6:42 PM Colin McCabe wrote:
> Hi David,
>
> Sounds good.
>
> best,
> Colin
>
>
> On Fri, Sep 13, 2019, at 04:45, David Jacot wrote:
> > Hi all,
> >
> > I would like to do another
partitions is not provided, all partitions are used.
Best,
David
Le mer. 18 sept. 2019 à 20:09, Colin McCabe a écrit :
> On Tue, Sep 17, 2019, at 09:07, David Jacot wrote:
> > Hi all,
> >
> > We haven't included the changes in the command line tool to support the
> new
&g
essary
> because--
> > > as you said-- the broker must look at a fixed offset to find the error
> > > code, regardless of the response version.
> > >
> > > I think we should force client software names and versions to follow a
> > > regular expression and disco
Hi all,
I have updated the KIP to incorporate Colin's feedback.
Best,
David
On Thu, Sep 19, 2019 at 8:44 AM David Jacot wrote:
> Hi Colin,
>
> Thank you for your feedback! Please find my comments/answers below:
>
> *> Nitpick: in the intro paragraph, "Operators of
be wrote:
> On Wed, Sep 18, 2019, at 23:44, David Jacot wrote:
> > Hi Colin,
> >
> > Thank you for your feedback! Please find my comments/answers below:
> >
> > *> Nitpick: in the intro paragraph, "Operators of Apache Kafka clusters
> > have literally
Great. I have updated the KIP.
Thanks,
David
On Thu, Sep 19, 2019 at 10:56 PM Colin McCabe wrote:
> Sounds good to me. It makes sense to add this functionality to the
> command line.
>
> best,
> Colin
>
> On Wed, Sep 18, 2019, at 11:26, David Jacot wrote:
> > Inde
t; wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > Thanks for the KIP, David and for the help with the design, Colin. I
> > > > think it looks great now.
> > > >
> > > > On Fri, Sep 20, 2019 at 9:42 AM Colin McCabe
> >
.
Best,
David
On Mon, Sep 23, 2019 at 9:28 AM David Jacot wrote:
> Hi Jason,
>
> The response will be a flexible version but the response header won't be
> (only for the api versions response). I have forgotten to change this point
> in the KIP. I will make this point clearer.
&g
; >
> > > 100. It seems that the new flexible fields need tag numbers. Could you
> > add
> > > them to the wiki?
> > >
> > > Jun
> > >
> > > On Mon, Sep 23, 2019 at 11:37 AM Jason Gustafson
> > > wrote:
> > >
> > >
Thanks for the KIP. It is a big +1 from me.
David
On Fri, Nov 8, 2019 at 2:56 AM Gwen Shapira wrote:
> About time :) Let's do it.
>
> On Thu, Nov 7, 2019 at 5:35 PM Ismael Juma wrote:
> >
> > Hi all,
> >
> > I think it's time to simplify our development environment by dropping
> > support for
Congrats Mickeal, well deserved!
On Fri, Nov 8, 2019 at 8:56 AM Tom Bentley wrote:
> Congratulations Mickael!
>
> On Fri, Nov 8, 2019 at 6:41 AM Vahid Hashemian
> wrote:
>
> > Congrats Mickael,
> >
> > Well deserved!
> >
> > --Vahid
> >
> > On Thu, Nov 7, 2019 at 9:10 PM Maulin Vasavada <
> mau
t; > Hi, David,
> >
> > Thanks for the KIP. The name QUOTA_VIOLATED sounds reasonable to me. +1
> on
> > the KIP.
> >
> > Jun
> >
> > On Tue, Jun 9, 2020 at 5:07 AM David Jacot wrote:
> >
> >> Hi Colin,
> >>
> >> Thank you
t; Jun
>
> On Tue, Jun 9, 2020 at 3:37 PM Colin McCabe wrote:
>
> > On Tue, Jun 9, 2020, at 05:06, David Jacot wrote:
> > > Hi Colin,
> > >
> > > Thank you for your feedback.
> > >
> > > Jun has summarized the situation pretty well. Thanks Jun
Hi Mickael,
Thanks for the KIP. That looks very useful.
I have few small comments/suggestions:
1. I was about the make a similar suggestion than Konstantine did regarding
requiring to recompile old formatters. While the formatters are not
directly part of the public API, I think that we can argu
y said in the KIP, I'll fix that
>
> Thanks
>
> On Wed, Jun 10, 2020 at 8:24 PM David Jacot wrote:
> >
> > Hi Mickael,
> >
> > Thanks for the KIP. That looks very useful.
> >
> > I have few small comments/suggestions:
> >
> > 1. I was
Colin, Jun,
Do the proposed error code and the updated KIP look good to you guys? I’d
like to wrap up and close the vote.
Thanks,
David
Le mer. 10 juin 2020 à 14:50, David Jacot a écrit :
> Hi Colin and Jun,
>
> I have no problem if we have to rewrite part of it when the new c
2020 at 10:08 PM Colin McCabe wrote:
> +1. Thanks, David!
>
> best,
> Colin
>
> On Thu, Jun 11, 2020, at 23:51, David Jacot wrote:
> > Colin, Jun,
> >
> > Do the proposed error code and the updated KIP look good to you guys? I’d
> > like to wrap u
+1 (non-binding)
Thanks for the KIP!
On Thu, Jun 18, 2020 at 12:00 AM Jose Garcia Sancio
wrote:
> +1.
>
> Thanks for the KIP and looking forward to the improvement implementation.
>
> On Wed, Jun 17, 2020 at 2:24 PM Guozhang Wang wrote:
> >
> > Thanks for the KIP Boyang, +1 from me.
> >
> >
>
ve time to move to the new interface. We will also remove the
> deprecated parts, including that method, in the next major release.
>
> On Thu, Jun 11, 2020 at 9:07 PM David Jacot wrote:
> >
> > Hi Mickael,
> >
> > Thanks for the updated KIP.
> >
> > 1) I
Hi Badai,
Thanks for resuming this. I have few small comments:
1. It seems that `print.partition` is already implemented. Do you confirm?
2. Will `null.literal` be only used when the value of the message
is NULL or for any fields? Also, it seems that we print out "null"
today when the key or the
user? For instance, we print out NO_TIMESTAMP
> where there is no timestamp.
> BADAI: Yes, good idea. I have updated the KIP to print NO_HEADERS.
>
> Thanks
> Badai
>
>
> On Thu, Jun 18, 2020 at 7:25 PM David Jacot wrote:
> >
> > Hi Badai,
> >
>
+1 (non-binding)
Thanks for the KIP!
Best,
David
On Fri, Jun 26, 2020 at 11:11 AM Manikumar
wrote:
> +1 (binding)
>
> Thanks for the KIP.
>
> Thans,
> Manikumar
>
> On Fri, Jun 26, 2020 at 11:46 AM Stanislav Kozlovski <
> stanis...@confluent.io>
> wrote:
>
> > +1 (non-binding).
> >
> > Thanks
+1 (non-binding). Thanks, Xavier!
On Fri, Jun 26, 2020 at 10:59 AM Levani Kokhreidze
wrote:
> +1 (non-binding)
>
> Thank you for this initiative.
>
> Levani
>
> > On Jun 26, 2020, at 11:53 AM, Mickael Maison
> wrote:
> >
> > +1 (binding)
> > Thanks for the KIP!
> >
> > On Fri, Jun 26, 2020 at 9
Congrats, Boyang!
On Thu, Jun 25, 2020 at 1:57 PM Viktor Somogyi-Vass
wrote:
> Congrats :)
>
> On Thu, Jun 25, 2020 at 12:28 AM Liquan Pei wrote:
>
> > Congrats!
> >
> > On Wed, Jun 24, 2020 at 9:42 AM Raymond Ng wrote:
> >
> > > Congrats Boyang! Look forward to more awesome contributions from
Congrats!
On Thu, Jun 25, 2020 at 4:08 PM Hu Xi wrote:
> Thank you, everyone. It is my great honor to be a part of the community.
> Will make a greater contribution in the coming days.
>
>
> 发件人: Roc Marshal
> 发送时间: 2020年6月25日 10:20
> 收件人: us...@kafka.apache.org
Hi Randall,
We have discovered an annoying issue that we introduced in 2.5:
Describing topics with the command line tool fails if the user does not
have the
privileges to access the ListPartitionReassignments API. I believe that
this is the
case for most non-admin users.
I propose to include the
Hi Tom,
I think that it is a useful addition. The KIP looks good to me.
Thanks,
David
Le mer. 1 juil. 2020 à 18:58, Manikumar a
écrit :
> Hi,
>
> Thanks for the KIP.
> KIP looks good to me and will be a useful addition.
>
> Thanks,
> Manikumar
>
> On Mon, Jun 29, 2020 at 4:05 PM Tom Bentley w
+1 (non-binding). Thanks for the KIP!
On Tue, Jul 7, 2020 at 12:54 PM Tom Bentley wrote:
> Hi,
>
> I'd like to start a vote on KIP-632, which is about making the config
> provider mechanism more ergonomic on Kubernetes:
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-632%3A+Add+Direc
I couldn't think of a better alternative either. Thanks for the KIP!
+1 (non-binding)
On Wed, Jul 8, 2020 at 12:42 PM Manikumar wrote:
> +1 (binding)
>
> Thanks for the KIP.
>
> On Tue, Jul 7, 2020 at 8:19 PM Colin McCabe wrote:
>
> > Thanks, Tom.
> >
> > I tried to think of a better way to do
Hi Badai,
Thanks for the KIP. I think that it is a nice improvement so I am +1
(non-binding).
Long term, I wonder if we could adopt a formatting system similar to
kafkacat. It
would reduce the number of properties that one has to set and also allow
more
powerful formatting. That could be done as
Hi Boyang,
Thanks for the update.
1./2. In KIP-599 (accepted and already in trunk), we throttle the
CreateTopicsRequest,
CreatePartitionsRequest, and DeleteTopicsRequests by muting the channel used
by the Admin client and setting the throttleTimeMs in the response. The
change that
you propose bre
o
a Double. I have made various experiments and the rate can be quite low,
especially
in clusters with a lot of tenants. Using a Long is quite limiting here to
fine tune small
rates. I hope that this change is fine for everyone.
Best,
David
On Mon, Jun 15, 2020 at 9:26 AM David Jacot wrote:
Hi, Colin, Boyang,
Colin, thanks for the clarification. Somehow, I thought that even if the
controller is ran independently, it
would still run the listeners of the broker and thus would be accessible by
redirecting on the loopback
interface. My mistake.
Boyang, I have few questions/comments rega
ized ones and not the whole original request
as is.
We may want to reword the sentence to make this clear.
- For the record, should we put the previous proposal in the rejected
alternatives as
well?
Best,
David
On Thu, Jul 30, 2020 at 3:51 AM Boyang Chen
wrote:
> Thanks David for the feed
Hi Daniel,
Thanks for the KIP.
It seems that we have forgotten to include this tool in KIP-499. KAFKA-8507
is resolved
by this tool still uses the deprecated "--broker-list". I suggest to
include "--bootstrap-server"
in your public interfaces as well and fix this omission during the
implementatio
the KIP to reflect this change.
We hope this change is fine for everyone. Please, raise your concerns if
not.
Best,
David
On Tue, Jul 28, 2020 at 1:48 PM David Jacot wrote:
> Hi all,
>
> Just a quick update. We have made good progress regarding the
> implementation
> of this
Supporting PEM is really nice. Thanks, Rajini.
+1 (non-binding)
On Thu, Aug 6, 2020 at 9:18 PM Gwen Shapira wrote:
> +1 (binding)
> Thank you for driving this, Rajini
>
> On Thu, Aug 6, 2020 at 10:43 AM Rajini Sivaram
> wrote:
>
> > Hi all,
> >
> > I would like to start vote on KIP-651 to supp
>
> > There is another PR linked on KAFKA-8507, which is still open:
> > https://github.com/apache/kafka/pull/8123
> > Wasn't sure if it will go in, and wanted to avoid conflicts. Do you think
> > I should do the switch to '--bootstrap-server' anyway?
&
nding)
> >>
> >> Thanks for the KIP, Anna!
> >>
> >> Regards,
> >>
> >> Rajini
> >>
> >>
> >> On Tue, May 19, 2020 at 9:32 AM Alexandre Dupriez <
> >> alexandre.dupr...@gmail.com> wrote:
> >>
> &
Hi Justine,
Thanks for the KIP. I finally had time to read it :). It is a great
improvement.
I have a few comments/questions:
1. It seems that the schema of the StopReplicaRequest is slightly outdated.
We
did some changes as part of KIP-570. V3 is already organized by topics.
2. I just want to
Hi Jack,
This is great! Thanks for doing it. I will look into it when I have a bit
of time, likely after Current.
Would you be interested in contributing it to the main repository? That
would be a great contribution to the project. Having it there would allow
the community to maintain it while ch
Hi Mayank,
Thanks again for the KIP and thanks for adding the new analysis. Overall, I
am fine with it. I have a few minor comments.
01. If I understand correctly, the client will still request a metadata
update even when it gets the new leader if the produce response or the
fetch response. Is th
Hi Andrew,
Thanks for driving this one. I haven't read all the KIP yet but I already
have an initial question. In the Threading section, it is written
"KafkaConsumer: the "background" thread (based on the consumer threading
refactor which is underway)". If I understand this correctly, it means
tha
Thanks for the KIP. +1 from me as well.
Best,
David
Le mar. 3 oct. 2023 à 20:54, Jun Rao a écrit :
> Hi, Mayank,
>
> Thanks for the detailed explanation in the KIP. +1 from me.
>
> Jun
>
> On Wed, Sep 27, 2023 at 4:39 AM Mayank Shekhar Narula <
> mayanks.nar...@gmail.com> wrote:
>
> > Reviving
Hi Calvin,
I thought that a new snapshot with the downgraded MV is created in this
case. Isn’t it the case?
Could you also elaborate a bit more on the reasoning behind adding the
limits to the admin RPCs? This is a new pattern in Kafka so it would be
good to clear on the motivation.
Could you al
Hi Erik,
Thanks for the KIP. I haven’t fully read the KIP yet but I agree with the
weaknesses that you point out in it. I will continue to read it.
For your information, we are working full speed on implementing KIP-848
while also changing the internal threading model of consumer. Those changes
a
> >
> > On Fri, Oct 13, 2023 at 11:54 PM Erik van Oosten
> > wrote:
> >
> >> Hello David,
> >>
> >> Thanks, I am happy to hear we agree on the problem. All the tiny details
> >> of an implementation are less important.
> >>
> >&
+1 (binding). Thanks for doing this!
Le dim. 29 oct. 2023 à 07:54, Manikumar a
écrit :
> Hi,
>
> Thanks for the KIP.
>
> +1 (binding)
>
> Thanks
>
> On Fri, Oct 27, 2023 at 9:41 PM Ismael Juma wrote:
>
> > Thanks for the KIP Krishna - looking forward to this. +1 (binding).
> >
> > On Thu, Oct 2
+1 from me as well. Thanks, Stan!
David
On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma wrote:
> Thanks Stanislav, +1
>
> Ismael
>
> On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> wrote:
>
> > Hi all,
> >
> > Given the discussion here and the lack of any pushback, I have changed
> the
> > dat
Hi all,
The state of our CI worries me a lot. Just this week, we merged two PRs
with compilation errors and one PR introducing persistent failures. This
really hurts the quality and the velocity of the project and it basically
defeats the purpose of having a CI because we tend to ignore it nowaday
+1 from me.
Thanks,
David
On Mon, Nov 20, 2023 at 10:48 PM Jason Gustafson
wrote:
> The KIP makes sense. +1
>
> On Mon, Nov 20, 2023 at 12:37 PM David Arthur
> wrote:
>
> > Thanks Colin,
> >
> > +1 from me
> >
> > -David
> >
> > On Tue, Nov 14, 2023 at 3:53 PM Colin McCabe wrote:
> >
> > > Hi
Hi all,
Thanks for the good discussion and all the comments. Overall, it seems that
we all agree on the bad state of our CI. That's a good first step!
I have talked to a few folks this week about it and it seems that many
folks (including me) are not comfortable with merging PRs at the moment
bec
9:35 AM Ismael Juma wrote:
> Hi David,
>
> Did you take a look at https://issues.apache.org/jira/browse/KAFKA-12216?
> I
> looked into this option already (yes, there isn't much that we haven't
> considered in this space).
>
> Ismael
>
> On Wed, Nov 2
n Wed, Nov 22, 2023 at 3:00 AM Ismael Juma wrote:
>
> > I think it breaks the Jenkins output otherwise. Feel free to test it via
> a
> > PR.
> >
> > Ismael
> >
> > On Wed, Nov 22, 2023, 12:42 AM David Jacot
> > wrote:
> >
> > >
Hi folks,
I have put together a very small KIP to
deprecate offsets.commit.required.acks in 3.8 and remove it in 4.0. See the
motivation for the reason.
KIP: https://cwiki.apache.org/confluence/x/9YobEg
Please let me know what you think.
Best,
David
Hi folks,
I'd like to start a voting thread for KIP-1041: Drop
`offsets.commit.required.acks` config in 4.0 (deprecate in 3.8).
KIP: https://cwiki.apache.org/confluence/x/9YobEg
Best,
David
> > > On Wed, May 8, 2024 at 5:27 PM Andrew Schofield
> > > wrote:
> > > >
> > > > Hi,
> > > > Thanks for the KIP.
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Thanks,
> > > > Andr
Hi Andrew,
Thanks for the KIP! This is really exciting! +1 (binding) from me.
One note regarding the partition assignor interface changes that you
proposed, it would be great to get the changes in 3.8 in order to not break
the API of KIP-848 after the preview.
Best,
David
On Wed, May 15, 2024 a
Hi all,
Thanks for the KIP. This is definitely a worthwhile feature. However, I am
a bit sceptical on the ZK part of the story. The 3.8 release is supposed to
be the last one supporting ZK so I don't really see how we could bring it
to ZK, knowing that we don't plan to do a 3.9 release (current pl
The plan sounds good to me. I suppose that we will follow our regular
cadence for 4.0 and release it four months after 3.9 (in November?). Is
this correct?
Best,
David
Le ven. 14 juin 2024 à 21:57, José Armando García Sancio
a écrit :
> +1 on the proposed release plan for 3.8.
>
> Thanks!
>
> O
riginally.
> >
> > The 3.9 one should really be an additional "out of schedule" release not
> > impacting any other releases.
> >
> >
> > -Matthias
> >
> > On 6/14/24 1:29 PM, David Jacot wrote:
> >> The plan sounds good to me. I su
+1 for the release plan. Thanks!
+1 for releasing 4.0 four months after 3.9. 4.0 is actually a pretty big
release as we will GA KIP-848, including new group coordinator and new
consumer rebalance protocol. This is a pretty big change :).
Best,
David
Le lun. 17 juin 2024 à 20:36, Colin McCabe a
cut.
David
Le lun. 17 juin 2024 à 19:33, Matthias J. Sax a écrit :
> Why would 4.0 be based on 3.8? My understanding is, that it will be
> based on 3.9.
>
> -Matthias
>
> On 6/14/24 11:22 PM, David Jacot wrote:
> > I agree that we should keep 4.0 time-based. My qu
Hi all,
I think that it would be nice to have an official way to enable
non-production-ready features in order to have a way to test them in
development/soak clusters. For instance, I would like the new consumer
protocol to be disabled by default but users should be able to enable it if
they want
Hi Colin,
I agree that we try hard to avoid breaking compatibility. I am not
questioning this at all. I also agree with your concern.
My point was about requiring users to opt-in for a feature vs having it
enabled by default during the EA and the Preview phases. With KIP-1022, the
only way to use
gt;>> >> > supported
> > >>> >> > > > > value is 0 for clients that send v3
> > >>> >> > > > >
> > >>> >> > > > > For 3.8, I planned to set the 0s in the response to 1. Is
> it
> > &g
Hi Omnia,
Thanks for the KIP. I agree that we should migrate admin APIs to the new
pattern.
DJ1: Why do we want to migrate only a subset of the APIs vs migrating all
of them? For instance, there are DescribeGroups, ConsumerGroupDescribe,
etc. Do we have reasons not to migrate them too? I think th
4, at 10:11, Jun Rao wrote:
> > Hi, David,
> >
> > Yes, that's another option. It probably has its own challenges. For
> > example, the FeatureCommand tool currently treats disabling a feature as
> > setting the version to 0. It would be useful to get Jose's opin
Hi Josep,
Thanks for starting the discussion.
We used Early Access, Preview and GA (or Production Ready) for KIP-848 and
I find it pretty nice. We could add the tentative release plan to the KIP's
header and it could be used as the source of truth.
Best,
David
On Wed, Jul 31, 2024 at 11:53 AM J
hat would
> indicate the state of the KIP, then using the "fixed version" label they'll
> be included in the release notes and the Release Manager can look for these
> special ones when writing announcements or making sure the release notes
> are up-to-date.
>
> Best,
1 - 100 of 1165 matches
Mail list logo
