Re: [DISCUSS] Road to Kafka 4.0

It may be worth starting a new thread with regards to the logging situation. Ismael On Wed, Jan 10, 2024 at 12:00 PM Mickael Maison wrote: > Hi Colin, > > Regarding KIP-719, I think need it to land in 3.8 if we want to remove > the appender in 4.0. I also just noticed the log4j's KafkaAppender

Re: [DISCUSS] Road to Kafka 4.0

Hi Colin, Regarding KIP-719, I think need it to land in 3.8 if we want to remove the appender in 4.0. I also just noticed the log4j's KafkaAppender is being deprecated in log4j2 and will not be part of log4j3. For KIP-653, as I said, my point was to gauge interest in getting it done. While it

Re: [DISCUSS] Road to Kafka 4.0

Hi Mickael, Thanks for bringing this up. The main motivation given in KIP-653 for moving to log4j 2.x is that log4j 1.x is no longer supported. But since we moved to reload4j, which is still supported, that isn't a concern any longer. To be clear, I'm not saying we shouldn't upgrade, but I'm

Re: [DISCUSS] Road to Kafka 4.0

Hi Ismael, Yes both KIPs have been voted. My point, which admittedly wasn't clear, was to gauge the interest in getting them done and if so identifying people to drive these tasks. KIP-719 shouldn't require too much more work to complete. There's a PR [0] which is relatively straightforward. I

Re: [DISCUSS] Road to Kafka 4.0

Hi Mickael, Given that KIP-653 was accepted, the current position is that we would move to log4j2 - provided that someone is available to drive that. It's also worth noting that log4j3 is now a thing (but not yet final): https://logging.apache.org/log4j/3.x/ Ismael On Thu, Jan 4, 2024 at 2:15 

Re: [DISCUSS] Road to Kafka 4.0

Hi, I've not seen replies about log4j2. The plan was to deprecated the appender (KIP-719) and switch to log4j2 (KIP-653). While reload4j works well, I'd still be in favor of switching to log4j2 in Kafka 4.0. Thanks, Mickael On Fri, Dec 29, 2023 at 2:19 AM Colin McCabe wrote: > > Hi all, > >

Re: [DISCUSS] Road to Kafka 4.0

Hi all, Let's continue this dicsussion on the "[DISCUSS] KIP-1012: The need for a Kafka 3.8.x release" email thread. Colin On Tue, Dec 26, 2023, at 12:50, José Armando García Sancio wrote: > Hi Divij, > > Thanks for the feedback. I agree that having a 3.8 release is > beneficial but some of

Re: [DISCUSS] Road to Kafka 4.0

Hi Divij, Thanks for the feedback. I agree that having a 3.8 release is beneficial but some of the comments in this message are inaccurate and could mislead the community and users. On Thu, Dec 21, 2023 at 7:00 AM Divij Vaidya wrote: > 1\ Durability/availability bugs in kraft - Even though

Re: [DISCUSS] Road to Kafka 4.0

Hi all, Discuss thread for KIP-1012 (The need for a Kafka 3.8 release) can be found under https://lists.apache.org/thread/kvdp2gmq5gd9txkvxh5vk3z2n55b04s5 Best, On Fri, Dec 22, 2023 at 4:00 AM Luke Chen wrote: > For release 3.8, I think we should also include the unclean leader election >

Re: [DISCUSS] Road to Kafka 4.0

For release 3.8, I think we should also include the unclean leader election support in KRaft. But we can discuss more details in the KIP. Thank you, Josep! And thank you all for the comments! Luke On Fri, Dec 22, 2023 at 1:14 AM Ismael Juma wrote: > Thank you Josep! > > Ismael > > On Thu, Dec

Re: [DISCUSS] Road to Kafka 4.0

Thank you Josep! Ismael On Thu, Dec 21, 2023, 9:09 AM Josep Prat wrote: > Hi Ismael, > > I can volunteer to write the KIP. Unless somebody else has any objections, > I'll get to write it by the end of this week. > > Best, > > Josep Prat > Open Source Engineering Director,

Re: [DISCUSS] Road to Kafka 4.0

Hi Ismael, I can volunteer to write the KIP. Unless somebody else has any objections, I'll get to write it by the end of this week. Best, Josep Prat Open Source Engineering Director, aivenjosep.p...@aiven.io | +491715557497 | aiven.io Aiven Deutschland GmbH Alexanderufer 3-7, 10117 Berlin

Re: [DISCUSS] Road to Kafka 4.0

Thanks, Ismael. The proposal makes sense. +1 David On Thu, Dec 21, 2023 at 5:59 PM Ismael Juma wrote: > Hi all, > > After understanding the use case Josep and Anton described in more detail, > I think it's fair to say that quorum reconfiguration is necessary for > migration of Apache Kafka

Re: [DISCUSS] Road to Kafka 4.0

Hi all, After understanding the use case Josep and Anton described in more detail, I think it's fair to say that quorum reconfiguration is necessary for migration of Apache Kafka users who follow this pattern. Given that, I think we should have a 3.8 release before the 4.0 release. The next

Re: [DISCUSS] Road to Kafka 4.0

Hey all, While I understand your points Divij, I am also not in favor of having two official release branches being developed at the same time. If we are really concerned about the metrics change or any other JIRA ticket, we can have a separate branch for that, rather than a new release branch. I

Re: [DISCUSS] Road to Kafka 4.0

Fair point David. The point of experimental release was to allow users to test the initial major version and allow for developers to start working on the major version. Even if we don't release, I think that there is value in starting a 4.x branch (separate from trunk). Having a 4.x branch will

Re: [DISCUSS] Road to Kafka 4.0

Hi Divij, Comments inline. On Thu, Dec 21, 2023 at 7:00 AM Divij Vaidya wrote: > 1\ Durability/availability bugs in kraft - Even though kraft has been > around for a while, we keep finding bugs that impact availability and data > durability in it almost with every release [1] [2]. It's a

Re: [DISCUSS] Road to Kafka 4.0

Hi Divij, > Release 4.0 as an "experimental" release I don't think that this is something that we should do. If we need more time, we should just do a 3.8 release and then release 4.0 when we are ready. An experimental major release will be more confusing than anything else. We should also keep

Re: [DISCUSS] Road to Kafka 4.0

Hi folks I am late to the conversation but I would like to add my point of view here. I have three main concerns: 1\ Durability/availability bugs in kraft - Even though kraft has been around for a while, we keep finding bugs that impact availability and data durability in it almost with every

Re: [DISCUSS] Road to Kafka 4.0

Hi Justine, Luke, and others, I believe a 3.8 version would make sense, and I would say KIP-853 should be part of it as well. Best, On Wed, Dec 20, 2023 at 4:11 PM Justine Olshan wrote: > Hey Luke, > > I think your point is valid. This is another good reason to have a 3.8 > release. > Would

Re: [DISCUSS] Road to Kafka 4.0

Hey Luke, I think your point is valid. This is another good reason to have a 3.8 release. Would you say that implementing KIP-966 in 3.8 would be an acceptable way to move forward? Thanks, Justine On Tue, Dec 19, 2023 at 4:35 AM Luke Chen wrote: > Hi Justine, > > Thanks for your reply. > > >

Re: [DISCUSS] Road to Kafka 4.0

Hi Justine, Thanks for your reply. > I think that for folks that want to prioritize availability over durability, the aggressive recovery strategy from KIP-966 should be preferable to the old unclean leader election configuration.

Re: [DISCUSS] Road to Kafka 4.0

Hey Luke -- There were some previous discussions on the mailing list about this but looks like we didn't file the ticket https://lists.apache.org/thread/sqsssos1d9whgmo92vdn81n9r5woy1wk When I asked some of the folks who worked on Kraft about this, they communicated to me that it was intentional

Re: [DISCUSS] Road to Kafka 4.0

Hi all, We found that currently (the latest trunk branch), the unclean leader election is not supported in KRaft mode. That is, when users enable `unclean.leader.election.enable` in KRaft mode, the config won't take effect and just behave like `unclean.leader.election.enable` is disabled.

Re: [DISCUSS] Road to Kafka 4.0

On Fri, Nov 24, 2023, at 03:47, Anton Agestam wrote: > In your last message you wrote: > > > But, on the KRaft side, I still maintain that nothing is missing except > > JBOD, which we already have a plan for. > > But earlier in this thread you mentioned an issue with "torn writes", > possibly

Re: [DISCUSS] Road to Kafka 4.0

Hi again Colin, I don't know at what point the discussion skewed from talking about migrations paths to talking about "production readiness". The concern I raised originally was about the former rather than the latter. In your last message you wrote: > But, on the KRaft side, I still maintain

Re: [DISCUSS] Road to Kafka 4.0

On Tue, Nov 21, 2023, at 19:30, Luke Chen wrote: > Yes, KIP-853 and disk failure support are both very important missing > features. For the disk failure support, I don't think this is a > "good-to-have-feature", it should be a "must-have" IMO. We can't announce > the 4.0 release without a good

Re: [DISCUSS] Road to Kafka 4.0

Hi Luke, I think we're conflating different things here. There are 3 separate points in your email, but only 1 of them requires 3.8: 1. JBOD may have some bugs in 3.7.0. Whatever bugs exist can be fixed in 3.7.x. We have already said that we will backport critical fixes to 3.7.x for some time.

Re: [DISCUSS] Road to Kafka 4.0

Hi Colin and Jose, I revisited the discussion of KIP-833 here , and you can see I'm the first one to reply to the discussion thread to express my excitement at that time. Till now, I personally still think having KRaft in Kafka is

Re: [DISCUSS] Road to Kafka 4.0

On Tue, Nov 21, 2023, at 03:47, Josep Prat wrote: > Hi Colin, > > I think it's great that Confluent runs KRaft clusters in production, > and it means that it is production ready for Confluent and it's users. > But luckily for Kafka, the community is bigger than this (self managed > in the cloud

Re: [DISCUSS] Road to Kafka 4.0

Hi Colin, I think it's great that Confluent runs KRaft clusters in production, and it means that it is production ready for Confluent and it's users. But luckily for Kafka, the community is bigger than this (self managed in the cloud or in-prem, or customers of other SaaS companies). We've

Re: [DISCUSS] Road to Kafka 4.0

Hi Josep, I think there is some confusion here. Quorum reconfiguration is not needed for KRaft to become production ready. Confluent runs thousands of KRaft clusters without quorum reconfiguration, and has for years. While dynamic quorum reconfiguration is a nice feature, it doesn't block

Re: [DISCUSS] Road to Kafka 4.0

Hi all, If we do a 3.8 release before 4.0 and we implement KIP-853 in 3.8, the user will be able to migrate to a KRaft cluster that supports dynamically changing the set of voters and has better support for disk failures. What are the disadvantages of adding the 3.8 release before 4.0? This

Re: [DISCUSS] Road to Kafka 4.0

Hi all, I wanted to share my opinion regarding this topic. I know some discussions happened some time ago (over a year) but I believe it's wise to reflect and re-evaluate if those decisions are still valid. KRaft, as of Kafka 3.6.x and 3.7.x, has not yet feature parity with Zookeeper. By

Re: [DISCUSS] Road to Kafka 4.0

On Tue, Nov 14, 2023, at 04:37, Anton Agestam wrote: > Hi Colin, > > Thank you for your thoughtful and comprehensive response. > >> KIP-853 is not a blocker for either 3.7 or 4.0. We discussed this in >> several KIPs that happened this year and last year. The most notable was >> probably KIP-866,

Re: [DISCUSS] Road to Kafka 4.0

Hi Colin, Thank you for your thoughtful and comprehensive response. > KIP-853 is not a blocker for either 3.7 or 4.0. We discussed this in several KIPs that happened this year and last year. The most notable was probably KIP-866, which was approved in May 2022. I understand this is the case,

Re: [DISCUSS] Road to Kafka 4.0

Hi Anton, It rarely makes sense to scale up and down the number of controller nodes in the cluster. Only one controller node will be active at any given time. The main reason to use 5 nodes would be to be able to tolerate 2 failures instead of 1. At Confluent, we generally run KRaft with 3

RE: [DISCUSS] Road to Kafka 4.0

Hi Luke, We have been looking into what switching from ZK to KRaft will mean for Aiven. We heavily depend on an “immutable infrastructure” model for deployments. This means that, when we perform upgrades, we introduce new nodes to our clusters, scale the cluster up to incorporate the new nodes,

RE: [DISCUSS] Road to Kafka 4.0

Hi Luke, We have been looking into what switching from ZK to KRaft will mean for Aiven. We heavily depend on an “immutable infrastructure” model for deployments. This means that, when we perform upgrades, we introduce new nodes to our clusters, scale the cluster up to incorporate the new nodes,

Re: [DISCUSS] Road to Kafka 4.0

More notes on this: As far as I can tell, KAFKA-15513 should be fixed by the recent SCRAM work. I hope someone can verify that this is the case. Proven and I commented on the JIRA. KAFKA-15489 is a bug fix but not a regression. Hence it doesn't block any new (or old) releases. While we have

Re: [DISCUSS] Road to Kafka 4.0

Hi Luke, As Ismael said, the only thing on that list that is a 4.0 blocker is KIP-858: JBOD support. It is the last remaining feature gap with ZK mode. We previously agreed that it needed to be implemented so that users of this feature could migrate to KRaft as planned. The good news is that

Re: [DISCUSS] Road to Kafka 4.0

Hi Luke, Thanks for starting this discussion. I think it's very important that we communicate our plans and progress to send a clear message to users. Regarding KRaft missing features, I tend to agree with Christopher that it would be much better to get them merged and declared production ready

Re: [DISCUSS] Road to Kafka 4.0

I think JBOD definitely needs to be before 4.0. That has been a blocker issue this entire time for me and my team and I'm sure others. While Kraft has been technically "production ready" for a while, I haven't been able to upgrade because of missing JBOD support. On Wed, Oct 11, 2023 at 12:15 PM

Re: [DISCUSS] Road to Kafka 4.0

Hi Luke, This is a good discussion. And there is a lot more to it than KRaft. With regards to KRaft, there are two separate items: 1. Bugs 2. Missing features when compared to ZK When it comes to bugs, I don't see why 4.0 is particularly relevant. KRaft has been considered production-ready for

[DISCUSS] Road to Kafka 4.0

Hi all, While Kafka 3.6.0 is released, I’d like to start the discussion for the “road to Kafka 4.0”. Based on the plan in KIP-833 , the next release 3.7 will be