REMINDER - Travel Assistance available for ApacheCon NA New Orleans 2022

Hi All Contributors and Committers, This is a first reminder email that travel assistance applications for ApacheCon NA 2022 are now open! We will be supporting ApacheCon North America in New Orleans, Louisiana, on October 3rd through 6th, 2022. TAC exists to help those that would like to attend

[GitHub] [kafka-site] mimaison merged pull request #379: MINOR: Update coding guide to mention need to maintain public client API compatibility

mimaison merged PR #379: URL: https://github.com/apache/kafka-site/pull/379 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@kafka.apache

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.2 #42

See

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #903

See

Re: [DISCUSS] KIP-827: Expose logdirs total and usable space via Kafka API

I understand your point but I think we could potentially improve the user experience here by sending different error codes for the following two different situations. Situation 1: "when broker hits an Exception accessing a logdir" -> UNKNOWN_SPACE Situation 2: "when feature is not supported" -> UNS

[VOTE] 3.2.0 RC1

Hello Kafka users, developers and client-developers, This is the second candidate for release of Apache Kafka 3.2.0. * log4j 1.x is replaced with reload4j (KAFKA-9366) * StandardAuthorizer for KRaft (KIP-801) * Send a hint to the partition leader to recover the partition (KIP-704) * Top-level er

Re: [VOTE] 3.1.1 RC1

+1 (non-binding). I used the Scala 2.13 binaries and staged Maven artifacts and ran various tests with them. Thanks for doing the release. Jakub On Fri, Apr 29, 2022 at 8:16 PM Mickael Maison wrote: > Hi Tom, > > Thanks for running this release! > > I've done the following: > - Checked signatur

Re: [DISCUSS] KIP-660: Pluggable ReplicaPlacer

Nice proposal. I can definitely see the value add it could bring based on varied custom use cases. 1. When exposing an interface external to Kafka, could we strive to ensure that the implementation can not mutate the incoming parameters? This would ensure that the implementations don't un-intentio

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.2 #43

See

Re: [VOTE] 3.2.0 RC1

Hi Bruno, Thanks for running the 3.2 release! I did the following: 1. Built from source 2. Ran the unit tests 3. Validated keys and checksums 4. Lightly checked the Javadoc 5. Ran the quickstart and the Kafka Streams demo app 6. Looked over the docs 7. Ran the KRaft quicksta

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #904

See

[jira] [Created] (KAFKA-13868) Website updates to satisfy Apache privacy policies

Mickael Maison created KAFKA-13868: -- Summary: Website updates to satisfy Apache privacy policies Key: KAFKA-13868 URL: https://issues.apache.org/jira/browse/KAFKA-13868 Project: Kafka Issue

[jira] [Created] (KAFKA-13869) Update quota callback metadata in KRaft

Jason Gustafson created KAFKA-13869: --- Summary: Update quota callback metadata in KRaft Key: KAFKA-13869 URL: https://issues.apache.org/jira/browse/KAFKA-13869 Project: Kafka Issue Type: Bug

Re: [DISCUSS] KIP-660: Pluggable ReplicaPlacer

Hi Mickael, We did discuss this earlier, and I remember not being too enthusiastic about a pluggable policy here :) There have been several changes to the placement code in the last few weeks. (These are examples of the kind of changes that are impossible to do once an API is established, by t

Re: [DISCUSS] KIP-827: Expose logdirs total and usable space via Kafka API

Hi Mickael, Thanks for the KIP. In the API, I would suggest using an OptionalLong rather than a "magic value" of -1. best, Colin On Thu, Apr 7, 2022, at 02:16, Mickael Maison wrote: > Hi, > > I wrote a small KIP to expose the total and usable space of logdirs > via the DescribeLogDirs API: >

[DISCUSS] KIP-833: Mark KRaft as Production Ready

Hi all, I've written a KIP for marking KRaft as production ready. Please take a look if you have a chance: https://cwiki.apache.org/confluence/x/8xKhD thanks, Colin

Re: [DISCUSS] KIP-833: Mark KRaft as Production Ready

Hi Colin, So exciting to see the KIP to mark the Kraft production ready! Just one comment: We should make sure the period between ZK deprecation (i.e. v3.4.0) to ZK removal (i.e. v4.0.0) is not too short. Do we have any expectation for the deprecation period? After all, this is not a small featur

Re: [DISCUSS] KIP-833: Mark KRaft as Production Ready

Hi Colin, Thanks for this KIP. I am very excited to see the proposal. A lot in the community have been asking when KRaft mode will be ready and I think this KIP will provide a lot of the answers and guidance desperately needed. Thanks for working on it. I also have some of the questions from Lu

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #905

See Changes: -- [...truncated 613973 lines...] [2022-05-04T05:32:14.666Z] [2022-05-04T05:32:14.666Z] org.apache.kafka.streams.processor.internals.StreamsAssignmentScaleTes

[jira] [Created] (KAFKA-13870) support both Suppressed untilTimeLimit and maxBytes without using emitEarlyWhenFull()

Anil created KAFKA-13870: Summary: support both Suppressed untilTimeLimit and maxBytes without using emitEarlyWhenFull() Key: KAFKA-13870 URL: https://issues.apache.org/jira/browse/KAFKA-13870 Project: Kafka

Re: [DISCUSS] KIP-833: Mark KRaft as Production Ready

On Tue, May 3, 2022, at 20:48, Israel Ekpo wrote: > Hi Colin, > > Thanks for this KIP. I am very excited to see the proposal. > > A lot in the community have been asking when KRaft mode will be ready and I > think this KIP will provide a lot of the answers and guidance desperately > needed. > > Tha

Re: [DISCUSS] KIP-833: Mark KRaft as Production Ready

On Tue, May 3, 2022, at 19:32, Luke Chen wrote: > Hi Colin, > > So exciting to see the KIP to mark the Kraft production ready! > > Just one comment: We should make sure the period between ZK deprecation > (i.e. v3.4.0) to ZK removal (i.e. v4.0.0) is not too short. > Do we have any expectation for t

Re: [DISCUSS] KIP-833: Mark KRaft as Production Ready

On Tue, May 3, 2022, at 23:16, Colin McCabe wrote: > > To be clear, the proposal here is to have the bridge release be 3.4 and > then move on to a ZK-free 4.0. With a 3.5 release as an option (but not > requirement) if we can't finish everything in time after 3.4. So that > would be two more rel