Re: Requesting permissions to create KIP

[Manikumar]

Thank you for your interest in Apache Kafka. Updated the permissions.

On Thu, Jun 6, 2024 at 1:15 PM Kaushik Raina
 wrote:
>
> Hello,
> Please provide permissions to create KIP. I indent to contribute to Apache
> kafka
>
> Wiki Id: kra...@confluent.io
> Jira ID: k-raina

[jira] [Resolved] (KAFKA-16826) Integrate Native Kafka Docker Image with github Actions

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-16826.
---
Fix Version/s: 3.8.0
   Resolution: Fixed

> Integrate Native Kafka Docker Image with github Actions
> ---
>
> Key: KAFKA-16826
> URL: https://issues.apache.org/jira/browse/KAFKA-16826
> Project: Kafka
>  Issue Type: Task
>Reporter: Krishna Agarwal
>Assignee: Krishna Agarwal
>Priority: Major
>  Labels: KIP-974
> Fix For: 3.8.0
>
>
> Integrate the Native Apache Kafka Docker Image with existing github actions
>  # Build and test
>  # Rc release
>  # Promote



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-1028: Docker Official Image for Apache Kafka

[Manikumar]

+1 (binding)

Thanks for the KIP.





On Tue, May 14, 2024, 9:46 PM Chris Egerton  wrote:

> +1 (binding), thanks for the KIP!
>
> On Tue, May 14, 2024, 12:13 Vedarth Sharma 
> wrote:
>
> > Hi everyone,
> >
> > I'd like to call a vote on KIP-1028 which aims to introduce a JVM based
> > Docker Official Image (DOI) for Apache Kafka.
> >
> > KIP -
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1028%3A+Docker+Official+Image+for+Apache+Kafka
> >
> > Discussion thread -
> > https://lists.apache.org/thread/6vvwx173jcbgj6vqoq6bo8c0k0ntym0w
> >
> > Thanks and regards,
> > Vedarth
> >
>

Re: [VOTE] KIP-1041: Drop `offsets.commit.required.acks` config in 4.0 (deprecate in 3.8)

[Manikumar]

+1 (binding).

Thanks for the KIP.

Manikumar

On Wed, May 8, 2024 at 9:55 PM Justine Olshan
 wrote:
>
> +1 (binding)
>
> Thanks,
> Justine
>
> On Wed, May 8, 2024 at 8:36 AM Federico Valeri  wrote:
>
> > +1 non binding
> >
> > Thanks
> >
> > On Wed, May 8, 2024 at 5:27 PM Andrew Schofield
> >  wrote:
> > >
> > > Hi,
> > > Thanks for the KIP.
> > >
> > > +1 (non-binding)
> > >
> > > Thanks,
> > > Andrew
> > >
> > > > On 8 May 2024, at 15:48, David Jacot 
> > wrote:
> > > >
> > > > 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
> > >
> >

Re: [VOTE] KIP-899: Allow producer and consumer clients to rebootstrap

[Manikumar]

Thanks for the KIP.

+1 (binding).

On Wed, Apr 17, 2024 at 7:50 PM Omnia Ibrahim  wrote:
>
> Hi Ivan,
> Thanks for the KIP this is a very nice feature to have.
> +1(non-binding)
> Omnia
> > On 15 Apr 2024, at 14:33, Andrew Schofield  
> > wrote:
> >
> > Thanks for the KIP
> >
> > +1 (non-binding)
> >
> > Andrew
> >
> >> On 15 Apr 2024, at 14:16, Chris Egerton  wrote:
> >>
> >> Hi Ivan,
> >>
> >> Thanks for the KIP. After the recent changes, this LGTM. +1 (binding)
> >>
> >> Cheers,
> >>
> >> Chris
> >>
> >> On Wed, Aug 2, 2023 at 12:15 AM Ivan Yurchenko 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> The discussion [1] for KIP-899 [2] has been open for quite some time. I'd
> >>> like to put the KIP up for a vote.
> >>>
> >>> Best,
> >>> Ivan
> >>>
> >>> [1] https://lists.apache.org/thread/m0ncbmfxs5m87sszby2jbmtjx2bdpcdl
> >>> [2]
> >>>
> >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-899%3A+Allow+producer+and+consumer+clients+to+rebootstrap
> >>>
> >
>

Re: [VOTE] KIP-932: Queues for Kafka

[Manikumar]

Hi Andrew,

Thanks for the KIP.  Great write-up!

+1 (binding)

Thanks,

On Wed, May 8, 2024 at 12:17 PM Satish Duggana  wrote:
>
> Hi Andrew,
> Thanks for the nice KIP, it will allow other messaging use cases to be
> onboarded to Kafka.
>
> +1 from me.
>
> Satish.
>
> On Tue, 7 May 2024 at 03:41, Jun Rao  wrote:
> >
> > Hi, Andrew,
> >
> > Thanks for the KIP. +1
> >
> > Jun
> >
> > On Mon, Mar 18, 2024 at 11:00 AM Edoardo Comar 
> > wrote:
> >
> > > Thanks Andrew,
> > >
> > > +1 (binding)
> > >
> > > Edo
> > >
> > > On Mon, 18 Mar 2024 at 16:32, Kenneth Eversole
> > >  wrote:
> > > >
> > > > Hi Andrew
> > > >
> > > > + 1 (Non-Binding)
> > > >
> > > > This will be great addition to Kafka
> > > >
> > > > On Mon, Mar 18, 2024 at 8:27 AM Apoorv Mittal 
> > > > wrote:
> > > >
> > > > > Hi Andrew,
> > > > > Thanks for writing the KIP. This is indeed going to be a valuable
> > > addition
> > > > > to the Kafka, excited to see the KIP.
> > > > >
> > > > > + 1 (Non-Binding)
> > > > >
> > > > > Regards,
> > > > > Apoorv Mittal
> > > > > +44 7721681581
> > > > >
> > > > >
> > > > > On Sun, Mar 17, 2024 at 11:16 PM Andrew Schofield <
> > > > > andrew_schofield_j...@outlook.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > > I’ve been working to complete KIP-932 over the past few months and
> > > > > > discussions have quietened down.
> > > > > >
> > > > > > I’d like to open the voting for KIP-932:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > >
> > >

Re: [DISCUSS] KIP-1028: Docker Official Image for Apache Kafka

[Manikumar]

Thanks Krish. KIP looks good to me.

On Wed, Apr 17, 2024 at 1:38 PM Krish Vora  wrote:
>
> Hi Manikumar,
>
> Thanks for the comments.
>
> Maybe as part of the release process, RM can create a JIRA for this
> > task. This can be taken by RM or any comitter or any contributor (with
> > some help from commiters to run "Docker Image Preparation via GitHub
> > Actions:"
>
> This sounds like a good idea. This step would be beneficial. By creating a
> JIRA ticket, it will also serve as a reminder to complete the post-release
> steps for the Docker official images. Have updated the KIP with this step.
>
> Is this using GitHub Actions workflow? or manual testing?
>
> This will be done by a Github Actions workflow, which will test the static
> Docker Official Image assets for a specific release version.
>
> Is it mandatory for RM/comitters to raise the PR to Docker Hub’s
> > official images repository (or) can it be done by any contributor.
>
> I believe that it can be done by any contributor (ref: This link
> <https://docs.docker.com/trusted-content/official-images/contributing/>
> quotes "*Anyone can provide feedback, contribute code, suggest process
> changes, or even propose a new Official Image.*")
>
> Also I was thinking, once the KIP gets voted, we should try to release
> > kafka:3.7.0 (or 3.7.1) Docker Official image. This will help us to
> > validate the process and allow us to fix any changes suggested by
> > Dockerhub before the 3.8.0 release.
>
> This sounds like a great idea. This KIP proposes release of DOI as a
> post-release process, which can be done anytime post release. Since 3.7.0
> is already released, we can perform these steps for that release too. By
> the time the KIP gets implemented, if 3.7.1 is released, we could do these
> steps for 3.7.1, instead of 3.7.0. This would allow us to make changes to
> the Dockerfiles and other assets based on feedback from Docker Hub before
> the release of version 3.8.0.
>
> Thanks,
> Krish.
>
> On Mon, Apr 15, 2024 at 12:59 PM Manikumar 
> wrote:
>
> > Hi Krish,
> >
> > Thanks for the updated KIP. a few comments below.
> >
> > > "These actions can be carried out by the RM or any contributor post the
> > release process."
> > Maybe as part of the release process, RM can create a JIRA for this
> > task. This can be taken by RM or any comitter or any contributor (with
> > some help from commiters to run "Docker Image Preparation via GitHub
> > Actions:"
> >
> > > "Perform Docker build tests to ensure image integrity"
> > Is this using GitHub Actions workflow? or manual testing?
> >
> > > "The RM will manually raise the final PR to Docker Hub’s official images
> > repository using the contents of the generated file"
> >  Is it mandatory for RM/comitters to raise the PR to Docker Hub’s
> > official images repository (or) can it be done by any contributor.
> >
> > Also I was thinking, once the KIP gets voted, we should try to release
> > kafka:3.7.0 (or 3.7.1) Docker Official image. This will help us to
> > validate the process and allow us to fix any changes suggested by
> > Dockerhub before the 3.8.0 release.
> >
> >
> > Thanks,
> >
> > On Mon, Apr 8, 2024 at 2:33 PM Krish Vora  wrote:
> > >
> > > Hi Manikumar and Luke.
> > > Thanks for the questions.
> > >
> > > 1. No, the Docker inventory files and configurations will not be the same
> > > for Open Source Software (OSS) Images and Docker Official Images (DOI).
> > >
> > > For OSS images, the Dockerfile located in docker/jvm/dockerfile is
> > > utilized. This process is integrated with the existing release pipeline
> > as
> > > outlined in KIP-975
> > > <
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-975%3A+Docker+Image+for+Apache+Kafka#KIP975:DockerImageforApacheKafka-Status
> > >,
> > > where the Kafka URL is provided as a build argument. This method allows
> > for
> > > building, testing, and releasing OSS images dynamically. The OSS images
> > > will continue to be released under the standard release process .
> > >
> > > In contrast, the release process for DOIs requires providing the Docker
> > Hub
> > > team with a specific directory for each version release that contains a
> > > standalone Dockerfile. These Dockerfiles are designed to be
> > > self-sufficient, hence require hardcoded values instead of relying on
> > build
> > > arguments. To accommodate this, in our prop

Re: [DISCUSS] KIP-1028: Docker Official Image for Apache Kafka

[Manikumar]

Hi Krish,

Thanks for the updated KIP. a few comments below.

> "These actions can be carried out by the RM or any contributor post the 
> release process."
Maybe as part of the release process, RM can create a JIRA for this
task. This can be taken by RM or any comitter or any contributor (with
some help from commiters to run "Docker Image Preparation via GitHub
Actions:"

> "Perform Docker build tests to ensure image integrity"
Is this using GitHub Actions workflow? or manual testing?

> "The RM will manually raise the final PR to Docker Hub’s official images 
> repository using the contents of the generated file"
 Is it mandatory for RM/comitters to raise the PR to Docker Hub’s
official images repository (or) can it be done by any contributor.

Also I was thinking, once the KIP gets voted, we should try to release
kafka:3.7.0 (or 3.7.1) Docker Official image. This will help us to
validate the process and allow us to fix any changes suggested by
Dockerhub before the 3.8.0 release.


Thanks,

On Mon, Apr 8, 2024 at 2:33 PM Krish Vora  wrote:
>
> Hi Manikumar and Luke.
> Thanks for the questions.
>
> 1. No, the Docker inventory files and configurations will not be the same
> for Open Source Software (OSS) Images and Docker Official Images (DOI).
>
> For OSS images, the Dockerfile located in docker/jvm/dockerfile is
> utilized. This process is integrated with the existing release pipeline as
> outlined in KIP-975
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-975%3A+Docker+Image+for+Apache+Kafka#KIP975:DockerImageforApacheKafka-Status>,
> where the Kafka URL is provided as a build argument. This method allows for
> building, testing, and releasing OSS images dynamically. The OSS images
> will continue to be released under the standard release process .
>
> In contrast, the release process for DOIs requires providing the Docker Hub
> team with a specific directory for each version release that contains a
> standalone Dockerfile. These Dockerfiles are designed to be
> self-sufficient, hence require hardcoded values instead of relying on build
> arguments. To accommodate this, in our proposed approach, a new directory
> named docker_official_images has been created. This directory contains
> version-specific directories, having Dockerfiles with hardcoded
> configurations for each release, acting as the source of truth for DOI
> releases. The hardcoded dockerfiles will be created using the
> docker/jvm/dockerfile as a template. Thus, as part of post release we will
> be creating a Dockerfile that will be reviewed by the Dockerhub community
> and might need changes as per their review. This approach ensures that DOIs
> are built consistently and meet the specific requirements set by Docker Hub.
>
> 2. Yes Manikumar, transitioning the release of Docker Official Images (DOI)
> to a post-release activity does address the concerns about complicating the
> release process. Initially, we considered incorporating DOI release
> directly into Kafka's release workflow. However, this approach
> significantly increased the RMs workload due to the addition of numerous
> steps, complicating the process. By designating the DOI release as a
> post-release task, we maintain the original release process. This
> adjustment allows for the DOI release to be done after the main release. We
> have revised the KIP to reflect that DOI releases will now occur after the
> main release phase. Please review the updated document and provide any
> feedback you might have.
>
> Thanks,
> Krish.
>
> On Wed, Apr 3, 2024 at 3:35 PM Luke Chen  wrote:
>
> > Hi Krishna,
> >
> > I also have the same question as Manikumar raised:
> > 1. Will the Docker inventory files/etc are the same for OSS Image and
> > Docker Official Images?
> > If no, then why not? Could we make them identical so that we don't have to
> > build 2 images for each release?
> >
> > Thank you.
> > Luke
> >
> > On Wed, Apr 3, 2024 at 12:41 AM Manikumar 
> > wrote:
> >
> > > Hi Krishna,
> > >
> > > Thanks for the KIP.
> > >
> > > I think Docker Official Images will be beneficial to the Kafka community.
> > > Few queries below.
> > >
> > > 1. Will the Docker inventory files/etc are the same for OSS Image and
> > > Docker Official Images
> > > 2. I am a bit worried about the new steps to the release process. Maybe
> > we
> > > should consider Docker Official Images release as Post-Release activity.
> > >
> > > Thanks,
> > >
> > > On Fri, Mar 22, 2024 at 3:29 PM Krish Vora 
> > wrote:
> > >
> > > > Hi Hector,
> > > >
>

Re: [ANNOUNCE] New Kafka PMC Member: Greg Harris

[Manikumar]

Congratulations, Greg.

On Mon, Apr 15, 2024 at 11:18 AM Bruno Cadonna  wrote:
>
> Congratulations, Greg!
>
> Best,
> Bruno
>
> On 4/15/24 7:33 AM, Claude Warren wrote:
> > Congrats Greg!  All the hard work paid off.
> >
> > On Mon, Apr 15, 2024 at 6:58 AM Ivan Yurchenko  wrote:
> >
> >> Congrats Greg!
> >>
> >> On Sun, Apr 14, 2024, at 22:51, Sophie Blee-Goldman wrote:
> >>> Congrats Greg! Happy to have you
> >>>
> >>> On Sun, Apr 14, 2024 at 9:26 AM Jorge Esteban Quilcate Otoya <
> >>> quilcate.jo...@gmail.com> wrote:
> >>>
>  Congrats, Greg!!
> 
>  On Sun 14. Apr 2024 at 15.05, Josep Prat 
>  wrote:
> 
> > Congrats Greg!!!
> >
> >
> > Best,
> >
> > Josep Prat
> > Open Source Engineering Director, aivenjosep.p...@aiven.io   |
> > +491715557497 | aiven.io
> > Aiven Deutschland GmbH
> > Alexanderufer 3-7, 10117 Berlin
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > On Sun, Apr 14, 2024, 12:30 Divij Vaidya 
>  wrote:
> >
> >> Congratulations Greg!
> >>
> >> --
> >> Divij Vaidya
> >>
> >>
> >>
> >> On Sun, Apr 14, 2024 at 6:39 AM Kamal Chandraprakash <
> >> kamal.chandraprak...@gmail.com> wrote:
> >>
> >>> Congratulations, Greg!
> >>>
> >>> On Sun, Apr 14, 2024 at 8:57 AM Yash Mayya  >>>
> > wrote:
> >>>
>  Congrats Greg!
> 
>  On Sun, 14 Apr, 2024, 05:56 Randall Hauch, 
>  wrote:
> 
> > Congratulations, Greg!
> >
> > On Sat, Apr 13, 2024 at 6:36 PM Luke Chen  >>>
> > wrote:
> >
> >> Congrats, Greg!
> >>
> >> On Sun, Apr 14, 2024 at 7:05 AM Viktor Somogyi-Vass
> >>  wrote:
> >>
> >>> Congrats Greg! :)
> >>>
> >>> On Sun, Apr 14, 2024, 00:35 Bill Bejeck <
> >> bbej...@gmail.com>
> >> wrote:
> >>>
>  Congrats Greg!
> 
>  -Bill
> 
>  On Sat, Apr 13, 2024 at 4:25 PM Boudjelda Mohamed Said
> >> <
> >>> bmsc...@gmail.com>
>  wrote:
> 
> > Congratulations Greg
> >
> > On Sat 13 Apr 2024 at 20:42, Chris Egerton <
> >>> ceger...@apache.org>
> >>> wrote:
> >
> >> Hi all,
> >>
> >> Greg Harris has been a Kafka committer since July
> >> 2023.
> > He
> >>> has
> >>> remained
> >> very active and instructive in the community since
> >> becoming a
>  committer.
> >> It's my pleasure to announce that Greg is now a
> >> member
>  of
> >>> Kafka
> >> PMC.
> >>
> >> Congratulations, Greg!
> >>
> >> Chris, on behalf of the Apache Kafka PMC
> >>
> >
> 
> >>>
> >>
> >
> 
> >>>
> >>
> >
> 
> >>>
> >>
> >
> >

[jira] [Resolved] (KAFKA-16473) KafkaDockerWrapper uses wrong cluster ID when formatting log dir

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-16473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-16473.
---
Fix Version/s: 3.8.0
   3.7.1
   Resolution: Fixed

> KafkaDockerWrapper uses wrong cluster ID when formatting log dir
> 
>
> Key: KAFKA-16473
> URL: https://issues.apache.org/jira/browse/KAFKA-16473
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Sebastian Marsching
>Priority: Major
> Fix For: 3.8.0, 3.7.1
>
>
> There is a bug in {{{}KafkaDockerWrapper{}}}, that causes {{Some( CLUSTER_ID environment variable>)}} to be used when formatting the log dir 
> when Kafka is started for the first time inside a Docker container.
> More specifically, the problem is in {{{}formatStorageCmd{}}}: The code uses 
> {{{}env.get("CLUSTER_ID"){}}}, but this returns an {{Option}} not a 
> {{{}String{}}}.
> The code should instead check whether the environment variable is set, 
> raising an exception if it is not set.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-1025: Optionally URL-encode clientID and clientSecret in authorization header

[Manikumar]

Thanks for the KIP.

+1 (binding)




On Mon, Apr 8, 2024 at 9:49 AM Kirk True  wrote:
>
> +1 (non-binding)
>
> Apologies. I thought I’d already voted :(
>
> > On Apr 7, 2024, at 10:48 AM, Nelson B.  wrote:
> >
> > Hi all,
> >
> > Just wanted to bump up this thread for visibility.
> >
> > Thanks!
> >
> > On Thu, Mar 28, 2024 at 3:40 AM Doğuşcan Namal 
> > wrote:
> >
> >> Thanks for checking it out Nelson. Yeah I think it makes sense to leave it
> >> for the users who want to use it for testing.
> >>
> >> On Mon, 25 Mar 2024 at 20:44, Nelson B.  wrote:
> >>
> >>> Hi Doğuşcan,
> >>>
> >>> Thanks for your vote!
> >>>
> >>> Currently, the usage of TLS depends on the protocol used by the
> >>> authorization server which is configured
> >>> through the "sasl.oauthbearer.token.endpoint.url" option. So, if the
> >>> URL address uses simple http (not https)
> >>> then secrets will be transmitted in plaintext. I think it's possible to
> >>> enforce using only https but I think any
> >>> production-grade authorization server uses https anyway and maybe users
> >> may
> >>> want to test using http in the dev environment.
> >>>
> >>> Thanks,
> >>>
> >>> On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal  >>>
> >>> wrote:
> >>>
>  Hi Nelson, thanks for the KIP.
> 
>  From the RFC:
>  ```
>  The authorization server MUST require the use of TLS as described in
>    Section 1.6 when sending requests using password authentication.
>  ```
> 
>  I believe we already have an enforcement for OAuth to be enabled only
> >> in
>  SSLChannel but would be good to double check. Sending secrets over
>  plaintext is a security bad practice :)
> 
>  +1 (non-binding) from me.
> 
>  On Tue, 19 Mar 2024 at 16:00, Nelson B. 
> >> wrote:
> 
> > Hi all,
> >
> > I would like to start a vote on KIP-1025
> > <
> >
> 
> >>>
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header
> >> ,
> > which would optionally URL-encode clientID and clientSecret in the
> > authorization header.
> >
> > I feel like all possible issues have been addressed in the discussion
> > thread.
> >
> > Thanks,
> >
> 
> >>>
> >>
>

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi Divij,

Thanks for letting me know. I missed it because the current announcement
email template does not mention it.
Added the 3.6.2 blog entry:
https://kafka.apache.org/blog#apache_kafka_362_release_announcement

Also updated the Release wiki instructions to include the blog details to
release announcement email


Thanks,


On Fri, Apr 5, 2024 at 5:34 PM Divij Vaidya  wrote:

> Hey Manikumar
>
> Are we planning to add the blog entry about the 3.6.2 release at
> https://kafka.apache.org/blog ? Asking because I didn't see this included
> in the release announcement.
>
> --
> Divij Vaidya
>
>
>
> On Wed, Mar 20, 2024 at 12:01 PM Manikumar 
> wrote:
>
> > Hi,
> >
> > We have one non-blocker issue to be resolved.
> > https://issues.apache.org/jira/browse/KAFKA-16073
> >
> > I plan to generate the first release candidate later today/tomorrow.
> >
> > Thanks.
> >
> >
> >
> > On Mon, Mar 18, 2024 at 11:28 PM Edoardo Comar 
> > wrote:
> >
> > > Thanks Manikumar, done and marked the issue as resolved
> > >
> > > On Mon, 18 Mar 2024 at 16:30, Manikumar 
> > wrote:
> > > >
> > > > Hi Edoardo,
> > > >
> > > > sure, pls go ahead and cherry-pick the changes to 3.7 and 3.6
> branches.
> > > >
> > > > Thanks,
> > > >
> > > > On Mon, Mar 18, 2024 at 3:53 PM Edoardo Comar  >
> > > wrote:
> > > >
> > > > > Hi Manikumar,
> > > > > https://issues.apache.org/jira/browse/KAFKA-16369
> > > > > is merged in trunk now.
> > > > > can you please cherry-pick it to 3.6.2 ?
> > > > >
> > > > > I didn't see it included in the plan, would you like me to add it ?
> > > > > I'd consider it a blocker since Kafka may stay up and running but
> > > useless
> > > > > ...
> > > > >
> > > > > On Mon, 18 Mar 2024 at 09:52, Manikumar  >
> > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have backported a couple of CVE related fixes to the 3.6
> branch.
> > > > > > https://issues.apache.org/jira/browse/KAFKA-16210
> > > > > > https://issues.apache.org/jira/browse/KAFKA-16322
> > > > > >
> > > > > >
> > > > > > We have one non-blocker issue to be resolved.
> > > > > > https://issues.apache.org/jira/browse/KAFKA-16073
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > On Fri, Mar 15, 2024 at 10:18 AM Ismael Juma 
> > > wrote:
> > > > > >
> > > > > > > Hi team,
> > > > > > >
> > > > > > > We should focus on regressions and cve fixes for releases like
> > > this one
> > > > > > > (second bug fix and it's not the most recently released
> version).
> > > The
> > > > > idea
> > > > > > > is to reduce the risk of regressions since it may well be the
> > last
> > > > > official
> > > > > > > release on this branch.
> > > > > > >
> > > > > > > Ismael
> > > > > > >
> > > > > > > On Thu, Mar 14, 2024, 1:39 AM Divij Vaidya <
> > > divijvaidy...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Manikumar,
> > > > > > > >
> > > > > > > > 1. Can you please take a look at
> > > > > > > > https://github.com/apache/kafka/pull/15490
> > > > > > > > which is a bug fix specific to the 3.6.x branch?
> > > > > > > > 2. Should we do a one-time update of all dependencies in
> 3.6.x
> > > branch
> > > > > > > > before releasing 3.6.2?
> > > > > > > > 3. We fixed quite a lot of flaky tests in 3.7.x. I will see
> if
> > > any
> > > > > > > > backporting is needed to make the release qualification
> easier.
> > > > > > > > 4. There are a large number of bugs reported as impacting
> 3.6.1
> > > [1]
> > > > > Some
> > > > > > > of
> > > > > > > > them have attached PRs and pending review. Maybe we can
> request
> > > all
> > > > > > > &

[ANNOUNCE] Apache Kafka 3.6.2

[Manikumar]

The Apache Kafka community is pleased to announce the release for
Apache Kafka 3.6.2

This is a bug fix release and it includes fixes and improvements from 28 JIRAs.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/3.6.2/RELEASE_NOTES.html


You can download the source and binary release (Scala 2.12 and Scala 2.13) from:
https://kafka.apache.org/downloads#3.6.2

---


Apache Kafka is a distributed streaming platform with four core APIs:


** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of application:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 40 contributors to this release!
(Please report an unintended omission)

Akhilesh Chaganti, Andrew Schofield, Anton Liauchuk, Bob Barrett,
Bruno Cadonna, Cheng-Kai, Zhang, Chia-Ping Tsai, Chris Egerton, Colin
P. McCabe, Colin Patrick McCabe, David Arthur, David Jacot, David Mao,
Divij Vaidya, Edoardo Comar, Emma Humber, Gaurav Narula, Greg Harris,
hudeqi, Ismael Juma, Jason Gustafson, Jim Galasyn, Joel Hamill, Johnny
Hsu, José Armando García Sancio, Justine Olshan, Luke Chen, Manikumar
Reddy, Matthias J. Sax, Mayank Shekhar Narula, Mickael Maison, Mike
Lloyd, Paolo Patierno, PoAn Yang, Ron Dagostino, Sagar Rao, Stanislav
Kozlovski, Walker Carlson, Yash Mayya

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Manikumar
Release Manager for Apache Kafka 3.6.2

Re: [VOTE] 3.6.2 RC2

[Manikumar]

Thanks all for voting.

I'm now closing the vote. The vote passes with
- 3 +1 bindings votes from Divij Vaidya, Justine, and Manikumar
- 3 +1 non-binding votes from Andrew, Jakub, and  Lianet
- 0 -1 votes

I'll go ahead and finish the release process.


Thanks,

On Thu, Apr 4, 2024 at 8:53 PM Manikumar  wrote:

> +1 (binding) from my side also.
>
> - verified the signatures, artifacts
> - ran the tests on the source archive
> - verified the quickstarts
>
>
> Thanks
>
> On Thu, Apr 4, 2024 at 7:46 PM Justine Olshan 
> wrote:
>
>> Thanks for clarifying Manikumar!
>>
>> +1 (binding) from me
>>
>> Justine
>>
>> On Thu, Apr 4, 2024 at 3:19 AM Divij Vaidya 
>> wrote:
>>
>> > Hi Manikumar
>> >
>> > I verified the following:
>> > - all non-minor commits in the branch are captured in release notes
>> > - signature on the artifact match the public signature of Manikumar
>> > - basic topic creation & produce / consumer works with JDK8 + ARM +
>> Kafka
>> > 3.6.2 + Scala 2.12 + ZK + compression (zstd)
>> >
>> > Things look good to me. We don't need another RC for fixing docs.
>> >
>> > +1 (binding) from me.
>> >
>> > --
>> > Divij Vaidya
>> >
>> >
>> >
>> > On Thu, Apr 4, 2024 at 10:04 AM Manikumar 
>> > wrote:
>> >
>> > > Hi Justine,
>> > >
>> > > Thanks for catching this. looks like we have missed updating
>> > > `docs/documentation.html` in kafka repo during 3.5 and 3.6 release.
>> > >
>> > > I will make sure to use the correct version when updating docs for
>> 3.6.2
>> > > release.
>> > > I will also update 3.5 and 3.6 branches with the correct heading and
>> also
>> > > update the release wiki.
>> > >
>> > > >what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
>> > > we will remove the "-SNAPSHOT" suffix while updating the website
>> docs. we
>> > > may need to automate this in the release script.
>> > >
>> > >
>> > > [1]
>> https://github.com/apache/kafka/blob/3.6/docs/documentation.html#L36
>> > > [2]
>> https://github.com/apache/kafka/blob/3.5/docs/documentation.html#L36
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > On Thu, Apr 4, 2024 at 3:50 AM Justine Olshan
>> > > > > >
>> > > wrote:
>> > >
>> > > > Thanks for clarifying!
>> > > > I took a look at the documentation.html file in there, and it said
>> 3.4.
>> > > Is
>> > > > that expected?
>> > > >
>> > > > There are some files that request fullDot version and that seemed
>> > closer
>> > > to
>> > > > what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
>> > > > The upgrade.html file also looked ok.
>> > > >
>> > > > Thanks for running the release and answering my questions!
>> > > > Justine
>> > > >
>> > > > On Wed, Apr 3, 2024 at 10:21 AM Manikumar <
>> manikumar.re...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hi Justine,
>> > > > >
>> > > > > Yes, it is intended. For bug fix releases website docs will be
>> > updated
>> > > > > during the final release process.
>> > > > > We can verify the site-docs artifacts here:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/kafka_2.12-3.6.2-site-docs.tgz
>> > > > > These site-docs artifacts will be used to update website docs.
>> > > > >
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > On Wed, Apr 3, 2024 at 10:30 PM Justine Olshan
>> > > > > 
>> > > > > wrote:
>> > > > >
>> > > > > > Hi Manikumar,
>> > > > > >
>> > > > > > I've verified the keys, scanned the artifacts, and other docs.
>> > > > > > I built from source and ran with a ZK cluster (since I saw that
>> we
>> > > > > updated
>> > > > > > ZK version in this release)
>> > > > >

Re: [VOTE] 3.6.2 RC2

[Manikumar]

+1 (binding) from my side also.

- verified the signatures, artifacts
- ran the tests on the source archive
- verified the quickstarts


Thanks

On Thu, Apr 4, 2024 at 7:46 PM Justine Olshan 
wrote:

> Thanks for clarifying Manikumar!
>
> +1 (binding) from me
>
> Justine
>
> On Thu, Apr 4, 2024 at 3:19 AM Divij Vaidya 
> wrote:
>
> > Hi Manikumar
> >
> > I verified the following:
> > - all non-minor commits in the branch are captured in release notes
> > - signature on the artifact match the public signature of Manikumar
> > - basic topic creation & produce / consumer works with JDK8 + ARM + Kafka
> > 3.6.2 + Scala 2.12 + ZK + compression (zstd)
> >
> > Things look good to me. We don't need another RC for fixing docs.
> >
> > +1 (binding) from me.
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Thu, Apr 4, 2024 at 10:04 AM Manikumar 
> > wrote:
> >
> > > Hi Justine,
> > >
> > > Thanks for catching this. looks like we have missed updating
> > > `docs/documentation.html` in kafka repo during 3.5 and 3.6 release.
> > >
> > > I will make sure to use the correct version when updating docs for
> 3.6.2
> > > release.
> > > I will also update 3.5 and 3.6 branches with the correct heading and
> also
> > > update the release wiki.
> > >
> > > >what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
> > > we will remove the "-SNAPSHOT" suffix while updating the website docs.
> we
> > > may need to automate this in the release script.
> > >
> > >
> > > [1]
> https://github.com/apache/kafka/blob/3.6/docs/documentation.html#L36
> > > [2]
> https://github.com/apache/kafka/blob/3.5/docs/documentation.html#L36
> > >
> > >
> > > Thanks,
> > >
> > > On Thu, Apr 4, 2024 at 3:50 AM Justine Olshan
> >  > > >
> > > wrote:
> > >
> > > > Thanks for clarifying!
> > > > I took a look at the documentation.html file in there, and it said
> 3.4.
> > > Is
> > > > that expected?
> > > >
> > > > There are some files that request fullDot version and that seemed
> > closer
> > > to
> > > > what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
> > > > The upgrade.html file also looked ok.
> > > >
> > > > Thanks for running the release and answering my questions!
> > > > Justine
> > > >
> > > > On Wed, Apr 3, 2024 at 10:21 AM Manikumar  >
> > > > wrote:
> > > >
> > > > > Hi Justine,
> > > > >
> > > > > Yes, it is intended. For bug fix releases website docs will be
> > updated
> > > > > during the final release process.
> > > > > We can verify the site-docs artifacts here:
> > > > >
> > > > >
> > > >
> > >
> >
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/kafka_2.12-3.6.2-site-docs.tgz
> > > > > These site-docs artifacts will be used to update website docs.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Wed, Apr 3, 2024 at 10:30 PM Justine Olshan
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > Hi Manikumar,
> > > > > >
> > > > > > I've verified the keys, scanned the artifacts, and other docs.
> > > > > > I built from source and ran with a ZK cluster (since I saw that
> we
> > > > > updated
> > > > > > ZK version in this release)
> > > > > > I ran a few tests on this cluster.
> > > > > >
> > > > > > I also ran the 2.12 binary.
> > > > > >
> > > > > > I noticed the docs link (
> > > > https://kafka.apache.org/36/documentation.html)
> > > > > > mentions 3.6.1 as the latest. Is that intended?
> > > > > > I will give my final vote when we figure this out.
> > > > > >
> > > > > > Thanks,
> > > > > > Justine
> > > > > >
> > > > > > On Wed, Apr 3, 2024 at 7:25 AM Lianet M. 
> > wrote:
> > > > > >
> > > > > > > Hi Manikumar, I did the following checks:
> > > > > > >
> > > > > > > - downloaded and built from sr

Re: [VOTE] 3.6.2 RC2

[Manikumar]

Hi Justine,

Thanks for catching this. looks like we have missed updating
`docs/documentation.html` in kafka repo during 3.5 and 3.6 release.

I will make sure to use the correct version when updating docs for 3.6.2
release.
I will also update 3.5 and 3.6 branches with the correct heading and also
update the release wiki.

>what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
we will remove the "-SNAPSHOT" suffix while updating the website docs. we
may need to automate this in the release script.


[1] https://github.com/apache/kafka/blob/3.6/docs/documentation.html#L36
[2] https://github.com/apache/kafka/blob/3.5/docs/documentation.html#L36


Thanks,

On Thu, Apr 4, 2024 at 3:50 AM Justine Olshan 
wrote:

> Thanks for clarifying!
> I took a look at the documentation.html file in there, and it said 3.4. Is
> that expected?
>
> There are some files that request fullDot version and that seemed closer to
> what was expected: "fullDotVersion": "3.6.2-SNAPSHOT"
> The upgrade.html file also looked ok.
>
> Thanks for running the release and answering my questions!
> Justine
>
> On Wed, Apr 3, 2024 at 10:21 AM Manikumar 
> wrote:
>
> > Hi Justine,
> >
> > Yes, it is intended. For bug fix releases website docs will be updated
> > during the final release process.
> > We can verify the site-docs artifacts here:
> >
> >
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/kafka_2.12-3.6.2-site-docs.tgz
> > These site-docs artifacts will be used to update website docs.
> >
> >
> > Thanks,
> >
> > On Wed, Apr 3, 2024 at 10:30 PM Justine Olshan
> > 
> > wrote:
> >
> > > Hi Manikumar,
> > >
> > > I've verified the keys, scanned the artifacts, and other docs.
> > > I built from source and ran with a ZK cluster (since I saw that we
> > updated
> > > ZK version in this release)
> > > I ran a few tests on this cluster.
> > >
> > > I also ran the 2.12 binary.
> > >
> > > I noticed the docs link (
> https://kafka.apache.org/36/documentation.html)
> > > mentions 3.6.1 as the latest. Is that intended?
> > > I will give my final vote when we figure this out.
> > >
> > > Thanks,
> > > Justine
> > >
> > > On Wed, Apr 3, 2024 at 7:25 AM Lianet M.  wrote:
> > >
> > > > Hi Manikumar, I did the following checks:
> > > >
> > > > - downloaded and built from src
> > > > - ran all unit test and integration test for clients
> > > > - ran quickstart with Kraft mode
> > > > - ran simple workloads with the console consumer/producer
> > > > - checked all links
> > > >
> > > > All looks good to me with this.
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Thanks!
> > > >
> > > >
> > > >
> > > > On Wed, Apr 3, 2024, 2:19 a.m. Manikumar 
> wrote:
> > > >
> > > > > Gentle reminder. Please download, test and vote for the release.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Fri, Mar 29, 2024 at 4:57 PM Manikumar 
> > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > System test runs are green. There were 13 test failures in the
> > first
> > > > run.
> > > > > > All the failed tests passed in the second run.
> > > > > >
> > > > > > System test results:
> > > > > >
> https://gist.github.com/omkreddy/17d23d3eb36ef840011f2494d65bbd4f
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > On Thu, Mar 28, 2024 at 3:21 PM Manikumar 
> > > > wrote:
> > > > > >
> > > > > >> Hello Kafka users, developers and client-developers,
> > > > > >>
> > > > > >> This is the second candidate we are considering for the release
> of
> > > > > Apache
> > > > > >> Kafka 3.6.2.
> > > > > >>
> > > > > >> This is a bugfix release with several fixes, including
> dependency
> > > > > >> version bumps for CVEs.
> > > > > >>
> > > > > >> Release notes for the 3.6.2 release:
> > > > > >>
> > > https://home.apache.org/~manikumar/kafka-3.6.2-rc2/RELEASE_NOTES.html
> > > > > >>
> > &g

Re: [VOTE] 3.6.2 RC2

[Manikumar]

Hi Justine,

Yes, it is intended. For bug fix releases website docs will be updated
during the final release process.
We can verify the site-docs artifacts here:
https://home.apache.org/~manikumar/kafka-3.6.2-rc2/kafka_2.12-3.6.2-site-docs.tgz
These site-docs artifacts will be used to update website docs.


Thanks,

On Wed, Apr 3, 2024 at 10:30 PM Justine Olshan 
wrote:

> Hi Manikumar,
>
> I've verified the keys, scanned the artifacts, and other docs.
> I built from source and ran with a ZK cluster (since I saw that we updated
> ZK version in this release)
> I ran a few tests on this cluster.
>
> I also ran the 2.12 binary.
>
> I noticed the docs link (https://kafka.apache.org/36/documentation.html)
> mentions 3.6.1 as the latest. Is that intended?
> I will give my final vote when we figure this out.
>
> Thanks,
> Justine
>
> On Wed, Apr 3, 2024 at 7:25 AM Lianet M.  wrote:
>
> > Hi Manikumar, I did the following checks:
> >
> > - downloaded and built from src
> > - ran all unit test and integration test for clients
> > - ran quickstart with Kraft mode
> > - ran simple workloads with the console consumer/producer
> > - checked all links
> >
> > All looks good to me with this.
> >
> > +1 (non-binding)
> >
> > Thanks!
> >
> >
> >
> > On Wed, Apr 3, 2024, 2:19 a.m. Manikumar  wrote:
> >
> > > Gentle reminder. Please download, test and vote for the release.
> > >
> > > Thanks,
> > >
> > > On Fri, Mar 29, 2024 at 4:57 PM Manikumar 
> wrote:
> > >
> > > > Hi All,
> > > >
> > > > System test runs are green. There were 13 test failures in the first
> > run.
> > > > All the failed tests passed in the second run.
> > > >
> > > > System test results:
> > > > https://gist.github.com/omkreddy/17d23d3eb36ef840011f2494d65bbd4f
> > > >
> > > > Thanks,
> > > >
> > > > On Thu, Mar 28, 2024 at 3:21 PM Manikumar 
> > wrote:
> > > >
> > > >> Hello Kafka users, developers and client-developers,
> > > >>
> > > >> This is the second candidate we are considering for the release of
> > > Apache
> > > >> Kafka 3.6.2.
> > > >>
> > > >> This is a bugfix release with several fixes, including dependency
> > > >> version bumps for CVEs.
> > > >>
> > > >> Release notes for the 3.6.2 release:
> > > >>
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/RELEASE_NOTES.html
> > > >>
> > > >> *** Please download, test and vote by by Wednesday, April 3rd
> > > >>
> > > >> Kafka's KEYS file containing PGP keys we use to sign the release:
> > > >> https://kafka.apache.org/KEYS
> > > >>
> > > >> * Release artifacts to be voted upon (source and binary):
> > > >> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/
> > > >>
> > > >>
> > > >> * Maven artifacts to be voted upon:
> > > >>
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > > >>
> > > >> * Javadoc:
> > > >> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/javadoc/
> > > >>
> > > >> * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
> > > >> https://github.com/apache/kafka/releases/tag/3.6.2-rc2
> > > >>
> > > >> * Documentation:
> > > >> https://kafka.apache.org/36/documentation.html
> > > >>
> > > >> * Protocol:
> > > >> https://kafka.apache.org/36/protocol.html
> > > >>
> > > >> * Successful Jenkins builds for the 3.6 branch:
> > > >> Unit/integration tests:
> > > >> https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.6/167/ (test
> > > >> failures passed in local runs)
> > > >> System tests: I will update system test results soon.
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Manikumar
> > > >>
> > > >
> > >
> >
>

Re: [VOTE] 3.6.2 RC2

[Manikumar]

Gentle reminder. Please download, test and vote for the release.

Thanks,

On Fri, Mar 29, 2024 at 4:57 PM Manikumar  wrote:

> Hi All,
>
> System test runs are green. There were 13 test failures in the first run.
> All the failed tests passed in the second run.
>
> System test results:
> https://gist.github.com/omkreddy/17d23d3eb36ef840011f2494d65bbd4f
>
> Thanks,
>
> On Thu, Mar 28, 2024 at 3:21 PM Manikumar  wrote:
>
>> Hello Kafka users, developers and client-developers,
>>
>> This is the second candidate we are considering for the release of Apache
>> Kafka 3.6.2.
>>
>> This is a bugfix release with several fixes, including dependency
>> version bumps for CVEs.
>>
>> Release notes for the 3.6.2 release:
>> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/RELEASE_NOTES.html
>>
>> *** Please download, test and vote by by Wednesday, April 3rd
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> https://kafka.apache.org/KEYS
>>
>> * Release artifacts to be voted upon (source and binary):
>> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/
>>
>>
>> * Maven artifacts to be voted upon:
>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>>
>> * Javadoc:
>> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/javadoc/
>>
>> * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
>> https://github.com/apache/kafka/releases/tag/3.6.2-rc2
>>
>> * Documentation:
>> https://kafka.apache.org/36/documentation.html
>>
>> * Protocol:
>> https://kafka.apache.org/36/protocol.html
>>
>> * Successful Jenkins builds for the 3.6 branch:
>> Unit/integration tests:
>> https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.6/167/ (test
>> failures passed in local runs)
>> System tests: I will update system test results soon.
>>
>>
>> Thanks,
>> Manikumar
>>
>

Re: [DISCUSS] KIP-1028: Docker Official Image for Apache Kafka

[Manikumar]

Hi Krishna,

Thanks for the KIP.

I think Docker Official Images will be beneficial to the Kafka community.
Few queries below.

1. Will the Docker inventory files/etc are the same for OSS Image and
Docker Official Images
2. I am a bit worried about the new steps to the release process. Maybe we
should consider Docker Official Images release as Post-Release activity.

Thanks,

On Fri, Mar 22, 2024 at 3:29 PM Krish Vora  wrote:

> Hi Hector,
>
> Thanks for reaching out. This KIP builds on top of KIP-975
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-975%3A+Docker+Image+for+Apache+Kafka
> >
> and
> aims to introduce a JVM-based Docker Official Image (DOI
> ) for Apache
> Kafka that will be visible under Docker Official Images
> . Once implemented
> for Apache Kafka, for each release, there will be one more JVM-based Docker
> image available to users.
>
> Currently, we already have an OSS sponsored image, which was introduced via
> KIP-975 (apache/kafka ) which
> comes under The Apache Software Foundation <
> https://hub.docker.com/u/apache> in
> Docker Hub. The new Docker Image is the Docker Official Image (DOI), which
> will be built and maintained by Docker Community.
>
> For example, for a release version like 3.8.0 we will have two JVM based
> docker images:-
>
>- apache/kafka:3.8.0 (OSS sponsored image)
>- kafka:3.8.0 (Docker Official image)
>
>
> I have added the same in the KIP too for everyone's reference.
> Thanks,
> Krish.
>
> On Fri, Mar 22, 2024 at 2:50 AM Hector Geraldino (BLOOMBERG/ 919 3RD A) <
> hgerald...@bloomberg.net> wrote:
>
> > Hi,
> >
> > What is the difference between this KIP and KIP-975: Docker Image for
> > Apache Kafka?
> >
> > From: dev@kafka.apache.org At: 03/21/24 07:30:07 UTC-4:00To:
> > dev@kafka.apache.org
> > Subject: [DISCUSS] KIP-1028: Docker Official Image for Apache Kafka
> >
> > Hi everyone,
> >
> > I would like to start the discussion on
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1028%3A+Docker+Official+Im
> > age+for+Apache+Kafka
> >  .
> >
> > This KIP aims to introduce JVM based Docker Official Image (DOI) for
> Apache
> > Kafka.
> >
> > Regards,
> > Krish.
> >
> >
> >
>

Re: [VOTE] 3.6.2 RC2

[Manikumar]

Hi All,

System test runs are green. There were 13 test failures in the first run.
All the failed tests passed in the second run.

System test results:
https://gist.github.com/omkreddy/17d23d3eb36ef840011f2494d65bbd4f

Thanks,

On Thu, Mar 28, 2024 at 3:21 PM Manikumar  wrote:

> Hello Kafka users, developers and client-developers,
>
> This is the second candidate we are considering for the release of Apache
> Kafka 3.6.2.
>
> This is a bugfix release with several fixes, including dependency
> version bumps for CVEs.
>
> Release notes for the 3.6.2 release:
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/RELEASE_NOTES.html
>
> *** Please download, test and vote by by Wednesday, April 3rd
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> https://kafka.apache.org/KEYS
>
> * Release artifacts to be voted upon (source and binary):
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/
>
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~manikumar/kafka-3.6.2-rc2/javadoc/
>
> * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
> https://github.com/apache/kafka/releases/tag/3.6.2-rc2
>
> * Documentation:
> https://kafka.apache.org/36/documentation.html
>
> * Protocol:
> https://kafka.apache.org/36/protocol.html
>
> * Successful Jenkins builds for the 3.6 branch:
> Unit/integration tests:
> https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.6/167/ (test
> failures passed in local runs)
> System tests: I will update system test results soon.
>
>
> Thanks,
> Manikumar
>

[VOTE] 3.6.2 RC2

[Manikumar]

Hello Kafka users, developers and client-developers,

This is the second candidate we are considering for the release of Apache
Kafka 3.6.2.

This is a bugfix release with several fixes, including dependency
version bumps for CVEs.

Release notes for the 3.6.2 release:
https://home.apache.org/~manikumar/kafka-3.6.2-rc2/RELEASE_NOTES.html

*** Please download, test and vote by by Wednesday, April 3rd

Kafka's KEYS file containing PGP keys we use to sign the release:
https://kafka.apache.org/KEYS

* Release artifacts to be voted upon (source and binary):
https://home.apache.org/~manikumar/kafka-3.6.2-rc2/


* Maven artifacts to be voted upon:
https://repository.apache.org/content/groups/staging/org/apache/kafka/

* Javadoc:
https://home.apache.org/~manikumar/kafka-3.6.2-rc2/javadoc/

* Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
https://github.com/apache/kafka/releases/tag/3.6.2-rc2

* Documentation:
https://kafka.apache.org/36/documentation.html

* Protocol:
https://kafka.apache.org/36/protocol.html

* Successful Jenkins builds for the 3.6 branch:
Unit/integration tests:
https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.6/167/ (test
failures passed in local runs)
System tests: I will update system test results soon.


Thanks,
Manikumar

[jira] [Reopened] (KAFKA-16310) ListOffsets doesn't report the offset with maxTimestamp anymore

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar reopened KAFKA-16310:
---

> ListOffsets doesn't report the offset with maxTimestamp anymore
> ---
>
> Key: KAFKA-16310
> URL: https://issues.apache.org/jira/browse/KAFKA-16310
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Emanuele Sabellico
>Assignee: Chia-Ping Tsai
>Priority: Blocker
> Fix For: 3.6.2, 3.8.0, 3.7.1
>
>
> Updated: This is confirmed a regression issue in v3.7.0. 
> The impact of this issue is that when there is a batch containing records 
> with timestamp not in order, the offset of the timestamp will be wrong.(ex: 
> the timestamp for t0 should be mapping to offset 10, but will get offset 12.. 
> etc). It'll cause the time index is putting the wrong offset, so the result 
> will be unexpected. 
> ===
> The last offset is reported instead.
> A test in librdkafka (0081/do_test_ListOffsets) is failing an it's checking 
> that the offset with the max timestamp is the middle one and not the last 
> one. The tests is passing with 3.6.0 and previous versions
> This is the test:
> [https://github.com/confluentinc/librdkafka/blob/a6d85bdbc1023b1a5477b8befe516242c3e182f6/tests/0081-admin.c#L4989]
>  
> there are three messages, with timestamps:
> {noformat}
> t0 + 100
> t0 + 400
> t0 + 250{noformat}
> and indices 0,1,2. 
> then a ListOffsets with RD_KAFKA_OFFSET_SPEC_MAX_TIMESTAMP is done.
> it should return offset 1 but in 3.7.0 and trunk is returning offset 2
> Even after 5 seconds from producing it's still returning 2 as the offset with 
> max timestamp.
> ProduceRequest and ListOffsets were sent to the same broker (2), the leader 
> didn't change.
> {code:java}
> %7|1709134230.019|SEND|0081_admin#producer-3| 
> [thrd:localhost:39951/bootstrap]: localhost:39951/2: Sent ProduceRequest (v7, 
> 206 bytes @ 0, CorrId 2) %7|1709134230.020|RECV|0081_admin#producer-3| 
> [thrd:localhost:39951/bootstrap]: localhost:39951/2: Received ProduceResponse 
> (v7, 95 bytes, CorrId 2, rtt 1.18ms) 
> %7|1709134230.020|MSGSET|0081_admin#producer-3| 
> [thrd:localhost:39951/bootstrap]: localhost:39951/2: 
> rdkafkatest_rnd22e8d8ec45b53f98_do_test_ListOffsets [0]: MessageSet with 3 
> message(s) (MsgId 0, BaseSeq -1) delivered {code}
> {code:java}
> %7|1709134235.021|SEND|0081_admin#producer-2| 
> [thrd:localhost:39951/bootstrap]: localhost:39951/2: Sent ListOffsetsRequest 
> (v7, 103 bytes @ 0, CorrId 7) %7|1709134235.022|RECV|0081_admin#producer-2| 
> [thrd:localhost:39951/bootstrap]: localhost:39951/2: Received 
> ListOffsetsResponse (v7, 88 bytes, CorrId 7, rtt 0.54ms){code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] 3.6.2 RC1

[Manikumar]

Hi,

Thanks for letting me know. Pls let me know after merging the PR. I will
generate RC2.


Thanks

On Sat, Mar 23, 2024 at 1:58 AM Colin McCabe  wrote:

> Sorry but I have to vote -1
>
> I tried verifying that the migration quotas bug described in
> https://issues.apache.org/jira/browse/KAFKA-16222 was fixed, and it
> appears to still be an issue with 3.6.2 RC1. The quota on the default
> resource is still getting translated improperly.
>
> I am looking into what the issue is here.
>
> best,
> Colin
>
>
> On Thu, Mar 21, 2024, at 19:32, Chia-Ping Tsai wrote:
> > hi Manikumar
> >
> >> Pls let me know after merging the PR. I will generate RC2 later today.
> >
> > Sure. We will complete it ASAP
> >
> >
> >> Manikumar  於 2024年3月22日 上午9:26 寫道：
> >>
> >> Hi,
> >>
> >> Thanks. Since we have merged KAFKA-16342
> >> <https://issues.apache.org/jira/browse/KAFKA-16342>, it's probably
> better
> >> to take the PR for KAFKA-16341
> >> <https://issues.apache.org/jira/browse/KAFKA-16341> for consistency.
> >> I am canceling the RC1 in favour of including KAFKA-16341
> >> <https://issues.apache.org/jira/browse/KAFKA-16341>.
> >>
> >> Chia-Ping,
> >>
> >> Pls let me know after merging the PR. I will generate RC2 later today.
> >>
> >>
> >> Thank you,
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Mar 21, 2024 at 9:10 PM Chia-Ping Tsai 
> wrote:
> >>
> >>>> Is this a regression from the 3.5.0 release?
> >>>
> >>> I believe the bug is existent for a while, but it is not a true issue
> until
> >>> we allowed users to fetch offset of max timestamp.
> >>>
> >>>> Can we update the "Affects Version/s" field on JIRA?
> >>>
> >>> done. I attach the tags for active branches - 3.6.1 and 3.7.0
> >>>
> >>> Manikumar  於 2024年3月21日 週四 下午11:12寫道：
> >>>
> >>>> Hi Chia-Ping,
> >>>>
> >>>> Thanks for letting me know.
> >>>>
> >>>> Is this a regression from the 3.5.0 release?  Can we update the
> "Affects
> >>>> Version/s" field on JIRA?
> >>>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>> On Thu, Mar 21, 2024 at 5:06 PM Chia-Ping Tsai 
> >>> wrote:
> >>>>
> >>>>> hi Manikumar,
> >>>>>
> >>>>> There is a bug fix which needs to be backport to 3.6 (
> >>>>> https://issues.apache.org/jira/browse/KAFKA-16341)
> >>>>>
> >>>>> It fixes the incorrect offset of max timestamp in non-compress path.
> >>> The
> >>>>> other paths are already fixed by
> >>>>> https://issues.apache.org/jira/browse/KAFKA-16342.
> >>>>>
> >>>>> Personally, we should backport both fixes for all paths, and we can
> >>>>> complete the backport today.
> >>>>>
> >>>>> Sorry for bring this news to RC1.
> >>>>>
> >>>>> Best,
> >>>>> Chia-Ping
> >>>>>
> >>>>>
> >>>>> Manikumar  於 2024年3月21日 週四 下午6:11寫道：
> >>>>>
> >>>>>> Hello Kafka users, developers and client-developers,
> >>>>>>
> >>>>>> This is the first candidate for release of Apache Kafka 3.6.2.
> >>>>>>
> >>>>>> This is a bugfix release with several fixes, including dependency
> >>>>>> version bumps for CVEs.
> >>>>>>
> >>>>>> Release notes for the 3.6.2 release:
> >>>>>>
> >>> https://home.apache.org/~manikumar/kafka-3.6.2-rc1/RELEASE_NOTES.html
> >>>>>>
> >>>>>> *** Please download, test and vote by Tuesday, March 26th
> >>>>>>
> >>>>>> Kafka's KEYS file containing PGP keys we use to sign the release:
> >>>>>> https://kafka.apache.org/KEYS
> >>>>>>
> >>>>>> * Release artifacts to be voted upon (source and binary):
> >>>>>> https://home.apache.org/~manikumar/kafka-3.6.2-rc1/
> >>>>>>
> >>>>>>
> >>>>>> * Maven artifacts to be voted upon:
> >>>>>>
> >>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >>>>>>
> >>>>>> * Javadoc:
> >>>>>> https://home.apache.org/~manikumar/kafka-3.6.2-rc1/javadoc/
> >>>>>>
> >>>>>> * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
> >>>>>> https://github.com/apache/kafka/releases/tag/3.6.2-rc1
> >>>>>>
> >>>>>> * Documentation:
> >>>>>> https://kafka.apache.org/36/documentation.html
> >>>>>>
> >>>>>> * Protocol:
> >>>>>> https://kafka.apache.org/36/protocol.html
> >>>>>>
> >>>>>> * Successful Jenkins builds for the 3.6 branch:
> >>>>>> Unit/integration tests:
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.6/159/tests
> >>>>>> (with few flaky failures)
> >>>>>> System tests: I will update system test results
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Manikumar
> >>>>>>
> >>>>>
> >>>>
> >>>
>

Re: [VOTE] 3.6.2 RC1

[Manikumar]

Hi,

Thanks. Since we have merged KAFKA-16342
<https://issues.apache.org/jira/browse/KAFKA-16342>, it's probably better
to take the PR for KAFKA-16341
<https://issues.apache.org/jira/browse/KAFKA-16341> for consistency.
I am canceling the RC1 in favour of including KAFKA-16341
<https://issues.apache.org/jira/browse/KAFKA-16341>.

Chia-Ping,

Pls let me know after merging the PR. I will generate RC2 later today.


Thank you,






On Thu, Mar 21, 2024 at 9:10 PM Chia-Ping Tsai  wrote:

> > Is this a regression from the 3.5.0 release?
>
> I believe the bug is existent for a while, but it is not a true issue until
> we allowed users to fetch offset of max timestamp.
>
> > Can we update the "Affects Version/s" field on JIRA?
>
> done. I attach the tags for active branches - 3.6.1 and 3.7.0
>
> Manikumar  於 2024年3月21日 週四 下午11:12寫道：
>
> > Hi Chia-Ping,
> >
> > Thanks for letting me know.
> >
> > Is this a regression from the 3.5.0 release?  Can we update the "Affects
> > Version/s" field on JIRA?
> >
> > Thanks,
> >
> >
> > On Thu, Mar 21, 2024 at 5:06 PM Chia-Ping Tsai 
> wrote:
> >
> > > hi Manikumar,
> > >
> > > There is a bug fix which needs to be backport to 3.6 (
> > > https://issues.apache.org/jira/browse/KAFKA-16341)
> > >
> > > It fixes the incorrect offset of max timestamp in non-compress path.
> The
> > > other paths are already fixed by
> > > https://issues.apache.org/jira/browse/KAFKA-16342.
> > >
> > > Personally, we should backport both fixes for all paths, and we can
> > > complete the backport today.
> > >
> > > Sorry for bring this news to RC1.
> > >
> > > Best,
> > > Chia-Ping
> > >
> > >
> > > Manikumar  於 2024年3月21日 週四 下午6:11寫道：
> > >
> > > > Hello Kafka users, developers and client-developers,
> > > >
> > > > This is the first candidate for release of Apache Kafka 3.6.2.
> > > >
> > > > This is a bugfix release with several fixes, including dependency
> > > > version bumps for CVEs.
> > > >
> > > > Release notes for the 3.6.2 release:
> > > >
> https://home.apache.org/~manikumar/kafka-3.6.2-rc1/RELEASE_NOTES.html
> > > >
> > > > *** Please download, test and vote by Tuesday, March 26th
> > > >
> > > > Kafka's KEYS file containing PGP keys we use to sign the release:
> > > > https://kafka.apache.org/KEYS
> > > >
> > > > * Release artifacts to be voted upon (source and binary):
> > > > https://home.apache.org/~manikumar/kafka-3.6.2-rc1/
> > > >
> > > >
> > > > * Maven artifacts to be voted upon:
> > > >
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > > >
> > > > * Javadoc:
> > > > https://home.apache.org/~manikumar/kafka-3.6.2-rc1/javadoc/
> > > >
> > > > * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
> > > > https://github.com/apache/kafka/releases/tag/3.6.2-rc1
> > > >
> > > > * Documentation:
> > > > https://kafka.apache.org/36/documentation.html
> > > >
> > > > * Protocol:
> > > > https://kafka.apache.org/36/protocol.html
> > > >
> > > > * Successful Jenkins builds for the 3.6 branch:
> > > > Unit/integration tests:
> > > >
> > > >
> > >
> >
> https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.6/159/tests
> > > > (with few flaky failures)
> > > > System tests: I will update system test results
> > > >
> > > > Thanks,
> > > > Manikumar
> > > >
> > >
> >
>

Re: [VOTE] 3.6.2 RC1

[Manikumar]

Hi Chia-Ping,

Thanks for letting me know.

Is this a regression from the 3.5.0 release?  Can we update the "Affects
Version/s" field on JIRA?

Thanks,


On Thu, Mar 21, 2024 at 5:06 PM Chia-Ping Tsai  wrote:

> hi Manikumar,
>
> There is a bug fix which needs to be backport to 3.6 (
> https://issues.apache.org/jira/browse/KAFKA-16341)
>
> It fixes the incorrect offset of max timestamp in non-compress path. The
> other paths are already fixed by
> https://issues.apache.org/jira/browse/KAFKA-16342.
>
> Personally, we should backport both fixes for all paths, and we can
> complete the backport today.
>
> Sorry for bring this news to RC1.
>
> Best,
> Chia-Ping
>
>
> Manikumar  於 2024年3月21日 週四 下午6:11寫道：
>
> > Hello Kafka users, developers and client-developers,
> >
> > This is the first candidate for release of Apache Kafka 3.6.2.
> >
> > This is a bugfix release with several fixes, including dependency
> > version bumps for CVEs.
> >
> > Release notes for the 3.6.2 release:
> > https://home.apache.org/~manikumar/kafka-3.6.2-rc1/RELEASE_NOTES.html
> >
> > *** Please download, test and vote by Tuesday, March 26th
> >
> > Kafka's KEYS file containing PGP keys we use to sign the release:
> > https://kafka.apache.org/KEYS
> >
> > * Release artifacts to be voted upon (source and binary):
> > https://home.apache.org/~manikumar/kafka-3.6.2-rc1/
> >
> >
> > * Maven artifacts to be voted upon:
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >
> > * Javadoc:
> > https://home.apache.org/~manikumar/kafka-3.6.2-rc1/javadoc/
> >
> > * Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
> > https://github.com/apache/kafka/releases/tag/3.6.2-rc1
> >
> > * Documentation:
> > https://kafka.apache.org/36/documentation.html
> >
> > * Protocol:
> > https://kafka.apache.org/36/protocol.html
> >
> > * Successful Jenkins builds for the 3.6 branch:
> > Unit/integration tests:
> >
> >
> https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.6/159/tests
> > (with few flaky failures)
> > System tests: I will update system test results
> >
> > Thanks,
> > Manikumar
> >
>

[VOTE] 3.6.2 RC1

[Manikumar]

Hello Kafka users, developers and client-developers,

This is the first candidate for release of Apache Kafka 3.6.2.

This is a bugfix release with several fixes, including dependency
version bumps for CVEs.

Release notes for the 3.6.2 release:
https://home.apache.org/~manikumar/kafka-3.6.2-rc1/RELEASE_NOTES.html

*** Please download, test and vote by Tuesday, March 26th

Kafka's KEYS file containing PGP keys we use to sign the release:
https://kafka.apache.org/KEYS

* Release artifacts to be voted upon (source and binary):
https://home.apache.org/~manikumar/kafka-3.6.2-rc1/


* Maven artifacts to be voted upon:
https://repository.apache.org/content/groups/staging/org/apache/kafka/

* Javadoc:
https://home.apache.org/~manikumar/kafka-3.6.2-rc1/javadoc/

* Tag to be voted upon (off 3.6 branch) is the 3.6.2 tag:
https://github.com/apache/kafka/releases/tag/3.6.2-rc1

* Documentation:
https://kafka.apache.org/36/documentation.html

* Protocol:
https://kafka.apache.org/36/protocol.html

* Successful Jenkins builds for the 3.6 branch:
Unit/integration tests:
https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.6/159/tests
(with few flaky failures)
System tests: I will update system test results

Thanks,
Manikumar

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi,

We have one non-blocker issue to be resolved.
https://issues.apache.org/jira/browse/KAFKA-16073

I plan to generate the first release candidate later today/tomorrow.

Thanks.



On Mon, Mar 18, 2024 at 11:28 PM Edoardo Comar 
wrote:

> Thanks Manikumar, done and marked the issue as resolved
>
> On Mon, 18 Mar 2024 at 16:30, Manikumar  wrote:
> >
> > Hi Edoardo,
> >
> > sure, pls go ahead and cherry-pick the changes to 3.7 and 3.6 branches.
> >
> > Thanks,
> >
> > On Mon, Mar 18, 2024 at 3:53 PM Edoardo Comar 
> wrote:
> >
> > > Hi Manikumar,
> > > https://issues.apache.org/jira/browse/KAFKA-16369
> > > is merged in trunk now.
> > > can you please cherry-pick it to 3.6.2 ?
> > >
> > > I didn't see it included in the plan, would you like me to add it ?
> > > I'd consider it a blocker since Kafka may stay up and running but
> useless
> > > ...
> > >
> > > On Mon, 18 Mar 2024 at 09:52, Manikumar 
> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have backported a couple of CVE related fixes to the 3.6 branch.
> > > > https://issues.apache.org/jira/browse/KAFKA-16210
> > > > https://issues.apache.org/jira/browse/KAFKA-16322
> > > >
> > > >
> > > > We have one non-blocker issue to be resolved.
> > > > https://issues.apache.org/jira/browse/KAFKA-16073
> > > >
> > > > Thanks,
> > > >
> > > > On Fri, Mar 15, 2024 at 10:18 AM Ismael Juma 
> wrote:
> > > >
> > > > > Hi team,
> > > > >
> > > > > We should focus on regressions and cve fixes for releases like
> this one
> > > > > (second bug fix and it's not the most recently released version).
> The
> > > idea
> > > > > is to reduce the risk of regressions since it may well be the last
> > > official
> > > > > release on this branch.
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Thu, Mar 14, 2024, 1:39 AM Divij Vaidya <
> divijvaidy...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Manikumar,
> > > > > >
> > > > > > 1. Can you please take a look at
> > > > > > https://github.com/apache/kafka/pull/15490
> > > > > > which is a bug fix specific to the 3.6.x branch?
> > > > > > 2. Should we do a one-time update of all dependencies in 3.6.x
> branch
> > > > > > before releasing 3.6.2?
> > > > > > 3. We fixed quite a lot of flaky tests in 3.7.x. I will see if
> any
> > > > > > backporting is needed to make the release qualification easier.
> > > > > > 4. There are a large number of bugs reported as impacting 3.6.1
> [1]
> > > Some
> > > > > of
> > > > > > them have attached PRs and pending review. Maybe we can request
> all
> > > > > > committers to take a look at the ones which have a PR attached
> and
> > > see if
> > > > > > we can close them in the next few days before 3.6.2. Note that
> this
> > > will
> > > > > be
> > > > > > on a best-effort basis and won't block release of 3.6.2.
> > > > > > 5. Have you looked at the JIRA marked as "bugs" in 3.7 and
> triaged
> > > > > whether
> > > > > > something needs to be backported? Usually it is the
> responsibility
> > > of the
> > > > > > reviewer but I have observed that sometimes we forget to backport
> > > > > important
> > > > > > onces as well. I can help with this one early next week.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > >
> https://issues.apache.org/jira/browse/KAFKA-16222?jql=project%20%3D%20KAFKA%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.6.1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Divij Vaidya
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Mar 14, 2024 at 7:55 AM Manikumar <
> manikumar.re...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > 

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi Edoardo,

sure, pls go ahead and cherry-pick the changes to 3.7 and 3.6 branches.

Thanks,

On Mon, Mar 18, 2024 at 3:53 PM Edoardo Comar  wrote:

> Hi Manikumar,
> https://issues.apache.org/jira/browse/KAFKA-16369
> is merged in trunk now.
> can you please cherry-pick it to 3.6.2 ?
>
> I didn't see it included in the plan, would you like me to add it ?
> I'd consider it a blocker since Kafka may stay up and running but useless
> ...
>
> On Mon, 18 Mar 2024 at 09:52, Manikumar  wrote:
> >
> > Hi,
> >
> > I have backported a couple of CVE related fixes to the 3.6 branch.
> > https://issues.apache.org/jira/browse/KAFKA-16210
> > https://issues.apache.org/jira/browse/KAFKA-16322
> >
> >
> > We have one non-blocker issue to be resolved.
> > https://issues.apache.org/jira/browse/KAFKA-16073
> >
> > Thanks,
> >
> > On Fri, Mar 15, 2024 at 10:18 AM Ismael Juma  wrote:
> >
> > > Hi team,
> > >
> > > We should focus on regressions and cve fixes for releases like this one
> > > (second bug fix and it's not the most recently released version). The
> idea
> > > is to reduce the risk of regressions since it may well be the last
> official
> > > release on this branch.
> > >
> > > Ismael
> > >
> > > On Thu, Mar 14, 2024, 1:39 AM Divij Vaidya 
> > > wrote:
> > >
> > > > Hi Manikumar,
> > > >
> > > > 1. Can you please take a look at
> > > > https://github.com/apache/kafka/pull/15490
> > > > which is a bug fix specific to the 3.6.x branch?
> > > > 2. Should we do a one-time update of all dependencies in 3.6.x branch
> > > > before releasing 3.6.2?
> > > > 3. We fixed quite a lot of flaky tests in 3.7.x. I will see if any
> > > > backporting is needed to make the release qualification easier.
> > > > 4. There are a large number of bugs reported as impacting 3.6.1 [1]
> Some
> > > of
> > > > them have attached PRs and pending review. Maybe we can request all
> > > > committers to take a look at the ones which have a PR attached and
> see if
> > > > we can close them in the next few days before 3.6.2. Note that this
> will
> > > be
> > > > on a best-effort basis and won't block release of 3.6.2.
> > > > 5. Have you looked at the JIRA marked as "bugs" in 3.7 and triaged
> > > whether
> > > > something needs to be backported? Usually it is the responsibility
> of the
> > > > reviewer but I have observed that sometimes we forget to backport
> > > important
> > > > onces as well. I can help with this one early next week.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> https://issues.apache.org/jira/browse/KAFKA-16222?jql=project%20%3D%20KAFKA%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.6.1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > > >
> > > >
> > > > --
> > > > Divij Vaidya
> > > >
> > > >
> > > >
> > > > On Thu, Mar 14, 2024 at 7:55 AM Manikumar  >
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Here is the release plan for 3.6.2:
> > > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+plan+3.6.2
> > > > >
> > > > > Currently there is one open non-blocker issue. I plan to generate
> the
> > > > first
> > > > > release candidate
> > > > > once the issue is resolved and no other issues are raised in the
> > > > meantime.
> > > > >
> > > > > Thanks,
> > > > > Manikumar
> > > > >
> > > > > On Thu, Mar 14, 2024 at 6:24 AM Satish Duggana <
> > > satish.dugg...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > +1, Thanks Mani for volunteering.
> > > > > >
> > > > > > On Thu, 14 Mar 2024 at 06:01, Luke Chen 
> wrote:
> > > > > > >
> > > > > > > +1, Thanks Manikumar!
> > > > > > >
> > > > > > > On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna <
> cado...@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks Manikumar!
> > > > > > > >
&

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi,

I have backported a couple of CVE related fixes to the 3.6 branch.
https://issues.apache.org/jira/browse/KAFKA-16210
https://issues.apache.org/jira/browse/KAFKA-16322


We have one non-blocker issue to be resolved.
https://issues.apache.org/jira/browse/KAFKA-16073

Thanks,

On Fri, Mar 15, 2024 at 10:18 AM Ismael Juma  wrote:

> Hi team,
>
> We should focus on regressions and cve fixes for releases like this one
> (second bug fix and it's not the most recently released version). The idea
> is to reduce the risk of regressions since it may well be the last official
> release on this branch.
>
> Ismael
>
> On Thu, Mar 14, 2024, 1:39 AM Divij Vaidya 
> wrote:
>
> > Hi Manikumar,
> >
> > 1. Can you please take a look at
> > https://github.com/apache/kafka/pull/15490
> > which is a bug fix specific to the 3.6.x branch?
> > 2. Should we do a one-time update of all dependencies in 3.6.x branch
> > before releasing 3.6.2?
> > 3. We fixed quite a lot of flaky tests in 3.7.x. I will see if any
> > backporting is needed to make the release qualification easier.
> > 4. There are a large number of bugs reported as impacting 3.6.1 [1] Some
> of
> > them have attached PRs and pending review. Maybe we can request all
> > committers to take a look at the ones which have a PR attached and see if
> > we can close them in the next few days before 3.6.2. Note that this will
> be
> > on a best-effort basis and won't block release of 3.6.2.
> > 5. Have you looked at the JIRA marked as "bugs" in 3.7 and triaged
> whether
> > something needs to be backported? Usually it is the responsibility of the
> > reviewer but I have observed that sometimes we forget to backport
> important
> > onces as well. I can help with this one early next week.
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/browse/KAFKA-16222?jql=project%20%3D%20KAFKA%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.6.1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Thu, Mar 14, 2024 at 7:55 AM Manikumar 
> > wrote:
> >
> > > Hi all,
> > >
> > > Here is the release plan for 3.6.2:
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+plan+3.6.2
> > >
> > > Currently there is one open non-blocker issue. I plan to generate the
> > first
> > > release candidate
> > > once the issue is resolved and no other issues are raised in the
> > meantime.
> > >
> > > Thanks,
> > > Manikumar
> > >
> > > On Thu, Mar 14, 2024 at 6:24 AM Satish Duggana <
> satish.dugg...@gmail.com
> > >
> > > wrote:
> > >
> > > > +1, Thanks Mani for volunteering.
> > > >
> > > > On Thu, 14 Mar 2024 at 06:01, Luke Chen  wrote:
> > > > >
> > > > > +1, Thanks Manikumar!
> > > > >
> > > > > On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna 
> > > > wrote:
> > > > >
> > > > > > Thanks Manikumar!
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > Best,
> > > > > > Bruno
> > > > > >
> > > > > > On 3/13/24 5:56 PM, Josep Prat wrote:
> > > > > > > +1 thanks for volunteering!
> > > > > > >
> > > > > > > Best
> > > > > > > ---
> > > > > > >
> > > > > > > Josep Prat
> > > > > > > Open Source Engineering Director, aivenjosep.p...@aiven.io   |
> > > > > > > +491715557497 | aiven.io
> > > > > > > Aiven Deutschland GmbH
> > > > > > > Alexanderufer 3-7, 10117 Berlin
> > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024, 17:17 Divij Vaidya <
> > divijvaidy...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> Thank you for volunteering.
> > > > > > >>
> > > > > > >> --
> > > > > > >> Divij Vaidya
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Wed, Mar 13, 2024 at 4:58 PM Justine Olshan
> > > > > > >> 
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Thanks Manikumar!
> > > > > > >>> +1 from me
> > > > > > >>>
> > > > > > >>> Justine
> > > > > > >>>
> > > > > > >>> On Wed, Mar 13, 2024 at 8:52 AM Manikumar <
> > > > manikumar.re...@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>>> Hi,
> > > > > > >>>>
> > > > > > >>>> I'd like to volunteer to be the release manager for a bug
> fix
> > > > release
> > > > > > >> of
> > > > > > >>>> the 3.6 line.
> > > > > > >>>> If there are no objections, I'll send out the release plan
> > soon.
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> Manikumar
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi Edoardo,

Sure, we can include KAFKA-16369
<https://issues.apache.org/jira/browse/KAFKA-16369> based PR reviews.

Thanks,

On Thu, Mar 14, 2024 at 3:16 PM Edoardo Comar  wrote:

> Hi Manikumar,
> can we please include
> https://issues.apache.org/jira/browse/KAFKA-16369
> in 3.6.2 ?
> While it's an issue still in trunk we actually discovered it our 3.6.1
> systems
>
> thanks,
> Edo
>
> On Thu, 14 Mar 2024 at 08:39, Divij Vaidya 
> wrote:
> >
> > Hi Manikumar,
> >
> > 1. Can you please take a look at
> https://github.com/apache/kafka/pull/15490
> > which is a bug fix specific to the 3.6.x branch?
> > 2. Should we do a one-time update of all dependencies in 3.6.x branch
> > before releasing 3.6.2?
> > 3. We fixed quite a lot of flaky tests in 3.7.x. I will see if any
> > backporting is needed to make the release qualification easier.
> > 4. There are a large number of bugs reported as impacting 3.6.1 [1] Some
> of
> > them have attached PRs and pending review. Maybe we can request all
> > committers to take a look at the ones which have a PR attached and see if
> > we can close them in the next few days before 3.6.2. Note that this will
> be
> > on a best-effort basis and won't block release of 3.6.2.
> > 5. Have you looked at the JIRA marked as "bugs" in 3.7 and triaged
> whether
> > something needs to be backported? Usually it is the responsibility of the
> > reviewer but I have observed that sometimes we forget to backport
> important
> > onces as well. I can help with this one early next week.
> >
> > [1]
> >
> https://issues.apache.org/jira/browse/KAFKA-16222?jql=project%20%3D%20KAFKA%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.6.1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Thu, Mar 14, 2024 at 7:55 AM Manikumar 
> wrote:
> >
> > > Hi all,
> > >
> > > Here is the release plan for 3.6.2:
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+plan+3.6.2
> > >
> > > Currently there is one open non-blocker issue. I plan to generate the
> first
> > > release candidate
> > > once the issue is resolved and no other issues are raised in the
> meantime.
> > >
> > > Thanks,
> > > Manikumar
> > >
> > > On Thu, Mar 14, 2024 at 6:24 AM Satish Duggana <
> satish.dugg...@gmail.com>
> > > wrote:
> > >
> > > > +1, Thanks Mani for volunteering.
> > > >
> > > > On Thu, 14 Mar 2024 at 06:01, Luke Chen  wrote:
> > > > >
> > > > > +1, Thanks Manikumar!
> > > > >
> > > > > On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna 
> > > > wrote:
> > > > >
> > > > > > Thanks Manikumar!
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > Best,
> > > > > > Bruno
> > > > > >
> > > > > > On 3/13/24 5:56 PM, Josep Prat wrote:
> > > > > > > +1 thanks for volunteering!
> > > > > > >
> > > > > > > Best
> > > > > > > ---
> > > > > > >
> > > > > > > Josep Prat
> > > > > > > Open Source Engineering Director, aivenjosep.p...@aiven.io   |
> > > > > > > +491715557497 | aiven.io
> > > > > > > Aiven Deutschland GmbH
> > > > > > > Alexanderufer 3-7, 10117 Berlin
> > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > > > >
> > > > > > > On Wed, Mar 13, 2024, 17:17 Divij Vaidya <
> divijvaidy...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> Thank you for volunteering.
> > > > > > >>
> > > > > > >> --
> > > > > > >> Divij Vaidya
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Wed, Mar 13, 2024 at 4:58 PM Justine Olshan
> > > > > > >> 
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Thanks Manikumar!
> > > > > > >>> +1 from me
> > > > > > >>>
> > > > > > >>> Justine
> > > > > > >>>
> > > > > > >>> On Wed, Mar 13, 2024 at 8:52 AM Manikumar <
> > > > manikumar.re...@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>>> Hi,
> > > > > > >>>>
> > > > > > >>>> I'd like to volunteer to be the release manager for a bug
> fix
> > > > release
> > > > > > >> of
> > > > > > >>>> the 3.6 line.
> > > > > > >>>> If there are no objections, I'll send out the release plan
> soon.
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> Manikumar
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > >
> > >
>

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi Divij,

1. I will take a look
2. I am not sure what we did for earlier releases. But we can update the
dependencies if any CVE exists
3. Thanks for looking into backports.
4. Sure, we can ping the committers  where PR is available
5. I have not looked at 3.7 bugs. I will also take a look.

Thanks,
Manikumar

On Thu, Mar 14, 2024 at 2:09 PM Divij Vaidya 
wrote:

> Hi Manikumar,
>
> 1. Can you please take a look at
> https://github.com/apache/kafka/pull/15490
> which is a bug fix specific to the 3.6.x branch?
> 2. Should we do a one-time update of all dependencies in 3.6.x branch
> before releasing 3.6.2?
> 3. We fixed quite a lot of flaky tests in 3.7.x. I will see if any
> backporting is needed to make the release qualification easier.
> 4. There are a large number of bugs reported as impacting 3.6.1 [1] Some of
> them have attached PRs and pending review. Maybe we can request all
> committers to take a look at the ones which have a PR attached and see if
> we can close them in the next few days before 3.6.2. Note that this will be
> on a best-effort basis and won't block release of 3.6.2.
> 5. Have you looked at the JIRA marked as "bugs" in 3.7 and triaged whether
> something needs to be backported? Usually it is the responsibility of the
> reviewer but I have observed that sometimes we forget to backport important
> onces as well. I can help with this one early next week.
>
> [1]
>
> https://issues.apache.org/jira/browse/KAFKA-16222?jql=project%20%3D%20KAFKA%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%203.6.1%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
>
> --
> Divij Vaidya
>
>
>
> On Thu, Mar 14, 2024 at 7:55 AM Manikumar 
> wrote:
>
> > Hi all,
> >
> > Here is the release plan for 3.6.2:
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+plan+3.6.2
> >
> > Currently there is one open non-blocker issue. I plan to generate the
> first
> > release candidate
> > once the issue is resolved and no other issues are raised in the
> meantime.
> >
> > Thanks,
> > Manikumar
> >
> > On Thu, Mar 14, 2024 at 6:24 AM Satish Duggana  >
> > wrote:
> >
> > > +1, Thanks Mani for volunteering.
> > >
> > > On Thu, 14 Mar 2024 at 06:01, Luke Chen  wrote:
> > > >
> > > > +1, Thanks Manikumar!
> > > >
> > > > On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna 
> > > wrote:
> > > >
> > > > > Thanks Manikumar!
> > > > >
> > > > > +1
> > > > >
> > > > > Best,
> > > > > Bruno
> > > > >
> > > > > On 3/13/24 5:56 PM, Josep Prat wrote:
> > > > > > +1 thanks for volunteering!
> > > > > >
> > > > > > Best
> > > > > > ---
> > > > > >
> > > > > > Josep Prat
> > > > > > Open Source Engineering Director, aivenjosep.p...@aiven.io   |
> > > > > > +491715557497 | aiven.io
> > > > > > Aiven Deutschland GmbH
> > > > > > Alexanderufer 3-7, 10117 Berlin
> > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > > >
> > > > > > On Wed, Mar 13, 2024, 17:17 Divij Vaidya <
> divijvaidy...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> +1
> > > > > >>
> > > > > >> Thank you for volunteering.
> > > > > >>
> > > > > >> --
> > > > > >> Divij Vaidya
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Mar 13, 2024 at 4:58 PM Justine Olshan
> > > > > >> 
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Thanks Manikumar!
> > > > > >>> +1 from me
> > > > > >>>
> > > > > >>> Justine
> > > > > >>>
> > > > > >>> On Wed, Mar 13, 2024 at 8:52 AM Manikumar <
> > > manikumar.re...@gmail.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> Hi,
> > > > > >>>>
> > > > > >>>> I'd like to volunteer to be the release manager for a bug fix
> > > release
> > > > > >> of
> > > > > >>>> the 3.6 line.
> > > > > >>>> If there are no objections, I'll send out the release plan
> soon.
> > > > > >>>>
> > > > > >>>> Thanks,
> > > > > >>>> Manikumar
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > >
> >
>

Re: [DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi all,

Here is the release plan for 3.6.2:
https://cwiki.apache.org/confluence/display/KAFKA/Release+plan+3.6.2

Currently there is one open non-blocker issue. I plan to generate the first
release candidate
once the issue is resolved and no other issues are raised in the meantime.

Thanks,
Manikumar

On Thu, Mar 14, 2024 at 6:24 AM Satish Duggana 
wrote:

> +1, Thanks Mani for volunteering.
>
> On Thu, 14 Mar 2024 at 06:01, Luke Chen  wrote:
> >
> > +1, Thanks Manikumar!
> >
> > On Thu, Mar 14, 2024 at 3:40 AM Bruno Cadonna 
> wrote:
> >
> > > Thanks Manikumar!
> > >
> > > +1
> > >
> > > Best,
> > > Bruno
> > >
> > > On 3/13/24 5:56 PM, Josep Prat wrote:
> > > > +1 thanks for volunteering!
> > > >
> > > > Best
> > > > ---
> > > >
> > > > Josep Prat
> > > > Open Source Engineering Director, aivenjosep.p...@aiven.io   |
> > > > +491715557497 | aiven.io
> > > > Aiven Deutschland GmbH
> > > > Alexanderufer 3-7, 10117 Berlin
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > On Wed, Mar 13, 2024, 17:17 Divij Vaidya 
> > > wrote:
> > > >
> > > >> +1
> > > >>
> > > >> Thank you for volunteering.
> > > >>
> > > >> --
> > > >> Divij Vaidya
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Mar 13, 2024 at 4:58 PM Justine Olshan
> > > >> 
> > > >> wrote:
> > > >>
> > > >>> Thanks Manikumar!
> > > >>> +1 from me
> > > >>>
> > > >>> Justine
> > > >>>
> > > >>> On Wed, Mar 13, 2024 at 8:52 AM Manikumar <
> manikumar.re...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> I'd like to volunteer to be the release manager for a bug fix
> release
> > > >> of
> > > >>>> the 3.6 line.
> > > >>>> If there are no objections, I'll send out the release plan soon.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Manikumar
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
>

[DISCUSS] Apache Kafka 3.6.2 release

[Manikumar]

Hi,

I'd like to volunteer to be the release manager for a bug fix release of
the 3.6 line.
If there are no objections, I'll send out the release plan soon.

Thanks,
Manikumar

Re: [DISCUSS] KIP-932: Queues for Kafka

[Manikumar]

Hi Andrew,

Thanks for the updated KIP. Few queries below:

1. What is the use-case of deliveryCount in ShareFetchResponse?
2. During delete share groups, Do we need to clean any in-memory state from
share-partition leaders?
3. Any metrics for the share-coordinator?

Thanks
Manikumar

On Wed, Feb 21, 2024 at 12:11 AM Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:

> Hi Manikumar,
> Thanks for your comments.
>
> 1. I believe that in general, there are not situations in which a dynamic
> config
> change is prevented because of the existence of a resource. So, if we
> prevented
> setting config `group.type=consumer` on resource G of GROUP type
> if there was a share group G in existence, it would be a bit weird.
>
> I wonder whether changing the config name to `new.group.type` would help.
> It’s
> ensuring the type of a new group created.
>
> 2. The behaviour for a DEAD share group is intended to be the same as a
> DEAD
> consumer group. The group cannot be “reused” again as such, but the group
> ID
> can be used by a new group.
>
> 3. Yes. AlterShareGroupOffsets will cause a new SHARE_CHECKPOINT.
>
> 4. In common with Admin.deleteConsumerGroups, the underlying Kafka RPC
> for Admin.deleteShareGroups is DeleteGroups. This is handled by the group
> coordinator and it does this by writing control records (a tombstone in
> this case).
> The KIP doesn’t say anything about this because it’s the same as consumer
> groups.
> Perhaps it would be sensible to add a GroupType to DeleteGroupsRequest so
> we can
> make sure we are deleting the correct type of group. The fact that there
> is not a specific
> RPC for DeleteShareGroups seems correct to me.
>
> 5. I prefer using “o.a.k.clients.consumer” because it’s already a public
> package and
> many of the classes and interfaces such as ConsumerRecord are in that
> package.
>
> I definitely need to add more information about how the Admin operations
> work.
> I will add a section to the KIP in the next version, later today. This
> will fill in details for
> your questions (3) and (4).
>
> Thanks,
> Andrew
>
> > On 14 Feb 2024, at 18:04, Manikumar  wrote:
> >
> > Hi Andrew,
> >
> > Thanks for the KIP. A few comments below.
> >
> > 1. kafka-configs.sh (incrementalAlterConfigs) allows you to dynamically
> > change the configs. Maybe in this case, we should not allow the user to
> > change `group.type` if it's already set.
> > 2. What's the behaviour after a group transitions into DEAD state. Do we
> > add new control records to reset the state? Can we reuse the group again?
> > 3. Are we going to write new control records after the
> > AlterShareGroupOffsets API to reset the state?
> > 4. Is there any API for DeleteShareGroups? I assume, group co-ordinator
> is
> > going to handle the API. If so, Does this mean the group co-ordinator
> also
> > needs to write control records?
> > 5. How about using "org.apache.kafka.clients.consumer.share" package for
> > new interfaces/classes?
> >
> >
> > Thanks,
> > Manikumar
>
>

Re: [kafka-clients] Re: [ANNOUNCE] Apache Kafka 3.7.0

[Manikumar]

Thanks Stanislav for running the release!



On Wed, Feb 28, 2024 at 2:36 PM Satish Duggana 
wrote:

> Thanks Stanislav for all your hard work on running the release. Thanks
> to all the contributors to this release.
>
>
> On Wed, 28 Feb 2024 at 13:43, Bruno Cadonna  wrote:
> >
> > Thanks Stan and all contributors for the release!
> >
> > Best,
> > Bruno
> >
> > On 2/27/24 7:01 PM, Stanislav Kozlovski wrote:
> > > The Apache Kafka community is pleased to announce the release of
> > > Apache Kafka 3.7.0
> > >
> > > This is a minor release that includes new features, fixes, and
> > > improvements from 296 JIRAs
> > >
> > > An overview of the release and its notable changes can be found in the
> > > release blog post:
> > > https://kafka.apache.org/blog#apache_kafka_370_release_announcement
> > >
> > > All of the changes in this release can be found in the release notes:
> > > https://www.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html
> > >
> > > You can download the source and binary release (Scala 2.12, 2.13) from:
> > > https://kafka.apache.org/downloads#3.7.0
> > >
> > >
> ---
> > >
> > >
> > > Apache Kafka is a distributed streaming platform with four core APIs:
> > >
> > >
> > > ** The Producer API allows an application to publish a stream of
> records to
> > > one or more Kafka topics.
> > >
> > > ** The Consumer API allows an application to subscribe to one or more
> > > topics and process the stream of records produced to them.
> > >
> > > ** The Streams API allows an application to act as a stream processor,
> > > consuming an input stream from one or more topics and producing an
> > > output stream to one or more output topics, effectively transforming
> the
> > > input streams to output streams.
> > >
> > > ** The Connector API allows building and running reusable producers or
> > > consumers that connect Kafka topics to existing applications or data
> > > systems. For example, a connector to a relational database might
> > > capture every change to a table.
> > >
> > >
> > > With these APIs, Kafka can be used for two broad classes of
> application:
> > >
> > > ** Building real-time streaming data pipelines that reliably get data
> > > between systems or applications.
> > >
> > > ** Building real-time streaming applications that transform or react
> > > to the streams of data.
> > >
> > >
> > > Apache Kafka is in use at large and small companies worldwide,
> including
> > > Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest,
> Rabobank,
> > > Target, The New York Times, Uber, Yelp, and Zalando, among others.
> > >
> > > A big thank you to the following 146 contributors to this release!
> > > (Please report an unintended omission)
> > >
> > > Abhijeet Kumar, Akhilesh Chaganti, Alieh, Alieh Saeedi, Almog Gavra,
> > > Alok Thatikunta, Alyssa Huang, Aman Singh, Andras Katona, Andrew
> > > Schofield, Anna Sophie Blee-Goldman, Anton Agestam, Apoorv Mittal,
> > > Arnout Engelen, Arpit Goyal, Artem Livshits, Ashwin Pankaj,
> > > ashwinpankaj, atu-sharm, bachmanity1, Bob Barrett, Bruno Cadonna,
> > > Calvin Liu, Cerchie, chern, Chris Egerton, Christo Lolov, Colin
> > > Patrick McCabe, Colt McNealy, Crispin Bernier, David Arthur, David
> > > Jacot, David Mao, Deqi Hu, Dimitar Dimitrov, Divij Vaidya, Dongnuo
> > > Lyu, Eaugene Thomas, Eduwer Camacaro, Eike Thaden, Federico Valeri,
> > > Florin Akermann, Gantigmaa Selenge, Gaurav Narula, gongzhongqiang,
> > > Greg Harris, Guozhang Wang, Gyeongwon, Do, Hailey Ni, Hanyu Zheng, Hao
> > > Li, Hector Geraldino, hudeqi, Ian McDonald, Iblis Lin, Igor Soarez,
> > > iit2009060, Ismael Juma, Jakub Scholz, James Cheng, Jason Gustafson,
> > > Jay Wang, Jeff Kim, Jim Galasyn, John Roesler, Jorge Esteban Quilcate
> > > Otoya, Josep Prat, José Armando García Sancio, Jotaniya Jeel, Jouni
> > > Tenhunen, Jun Rao, Justine Olshan, Kamal Chandraprakash, Kirk True,
> > > kpatelatwork, kumarpritam863, Laglangyue, Levani Kokhreidze, Lianet
> > > Magrans, Liu Zeyu, Lucas Brutschy, Lucia Cerchie, Luke Chen, maniekes,
> > > Manikumar Reddy, mannoopj, Maros Orsak, Matthew de Detrich, Matthias
> > > J. Sax, Max Riedel, Mayank Shekhar Narula, Me

Re: [VOTE] KIP-1019: Expose method to determine Metric Measurability

[Manikumar]

+1 (binding).

Thanks for the KIP.

Manikumar

On Tue, Feb 20, 2024 at 2:31 PM Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:

> Hi Apoorv,
> Thanks for the KIP.
>
> +1 (non-binding)
>
> Thanks,
> Andrew
>
> > On 19 Feb 2024, at 22:31, Apoorv Mittal 
> wrote:
> >
> > Hi,
> > I’d like to start the voting for KIP-1019: Expose method to determine
> > Metric Measurability.
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1019%3A+Expose+method+to+determine+Metric+Measurability
> >
> > Regards,
> > Apoorv Mittal
>
>

Re: [Discuss] KIP-1019: Expose method to determine Metric Measurability

[Manikumar]

LGTM, Thanks for the KIP.

On Thu, Feb 15, 2024 at 8:50 PM Doğuşcan Namal 
wrote:

> LGTM thanks for the KIP.
>
> +1(non-binding)
>
> On Wed, 14 Feb 2024 at 15:22, Andrew Schofield <
> andrew_schofield_j...@outlook.com> wrote:
>
> > Hi Apoorv,
> > Thanks for the KIP. Looks like a useful change to tidy up the metrics
> code.
> >
> > Thanks,
> > Andrew
> >
> > > On 14 Feb 2024, at 14:55, Apoorv Mittal 
> > wrote:
> > >
> > > Hi,
> > > I would like to start discussion of a small KIP which fills a gap in
> > > determining Kafka Metric measurability.
> > >
> > > KIP-1019: Expose method to determine Metric Measurability
> > > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1019%3A+Expose+method+to+determine+Metric+Measurability
> > >
> > >
> > > Regards,
> > > Apoorv Mittal
> >
> >
>

Re: [DISCUSS] KIP-932: Queues for Kafka

[Manikumar]

Hi Andrew,

Thanks for the KIP. A few comments below.

1. kafka-configs.sh (incrementalAlterConfigs) allows you to dynamically
change the configs. Maybe in this case, we should not allow the user to
change `group.type` if it's already set.
2. What's the behaviour after a group transitions into DEAD state. Do we
add new control records to reset the state? Can we reuse the group again?
3. Are we going to write new control records after the
AlterShareGroupOffsets API to reset the state?
4. Is there any API for DeleteShareGroups? I assume, group co-ordinator is
going to handle the API. If so, Does this mean the group co-ordinator also
needs to write control records?
5. How about using "org.apache.kafka.clients.consumer.share" package for
new interfaces/classes?


Thanks,
Manikumar

[jira] [Resolved] (KAFKA-15738) KRaft support in ConsumerWithLegacyMessageFormatIntegrationTest

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15738.
---
Fix Version/s: 3.8.0
   Resolution: Fixed

> KRaft support in ConsumerWithLegacyMessageFormatIntegrationTest
> ---
>
> Key: KAFKA-15738
> URL: https://issues.apache.org/jira/browse/KAFKA-15738
> Project: Kafka
>  Issue Type: Task
>  Components: core
>Reporter: Sameer Tejani
>Assignee: Abhinav Dixit
>Priority: Minor
>  Labels: kraft, kraft-test, newbie
> Fix For: 3.8.0
>
>
> The following tests in ConsumerWithLegacyMessageFormatIntegrationTest in 
> core/src/test/scala/integration/kafka/api/ConsumerWithLegacyMessageFormatIntegrationTest.scala
>  need to be updated to support KRaft
> 0 : def testOffsetsForTimes(): Unit = {
> 102 : def testEarliestOrLatestOffsets(): Unit = {
> Scanned 132 lines. Found 0 KRaft tests out of 2 tests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15735) KRaft support in SaslMultiMechanismConsumerTest

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15735.
---
Fix Version/s: 3.8.0
   Resolution: Fixed

> KRaft support in SaslMultiMechanismConsumerTest
> ---
>
> Key: KAFKA-15735
> URL: https://issues.apache.org/jira/browse/KAFKA-15735
> Project: Kafka
>  Issue Type: Task
>  Components: core
>Reporter: Sameer Tejani
>Assignee: Sanskar Jhajharia
>Priority: Minor
>  Labels: kraft, kraft-test, newbie
> Fix For: 3.8.0
>
>
> The following tests in SaslMultiMechanismConsumerTest in 
> core/src/test/scala/integration/kafka/api/SaslMultiMechanismConsumerTest.scala
>  need to be updated to support KRaft
> 45 : def testMultipleBrokerMechanisms(): Unit = {
> Scanned 94 lines. Found 0 KRaft tests out of 1 tests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15726) KRaft support in ProduceRequestTest

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15726.
---
Fix Version/s: 3.8.0
   Resolution: Fixed

> KRaft support in ProduceRequestTest
> ---
>
> Key: KAFKA-15726
> URL: https://issues.apache.org/jira/browse/KAFKA-15726
> Project: Kafka
>  Issue Type: Task
>  Components: core
>Reporter: Sameer Tejani
>Priority: Minor
>  Labels: kraft, kraft-test, newbie
> Fix For: 3.8.0
>
>
> The following tests in ProduceRequestTest in 
> core/src/test/scala/unit/kafka/server/ProduceRequestTest.scala need to be 
> updated to support KRaft
> 45 : def testSimpleProduceRequest(): Unit = {
> 82 : def testProduceWithInvalidTimestamp(): Unit = {
> 128 : def testProduceToNonReplica(): Unit = {
> 170 : def testCorruptLz4ProduceRequest(): Unit = {
> 204 : def testZSTDProduceRequest(): Unit = {
> Scanned 253 lines. Found 0 KRaft tests out of 5 tests



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15904) Downgrade tests are failing with directory.id

[Manikumar (Jira)]

Manikumar created KAFKA-15904:
-

 Summary: Downgrade tests are failing with directory.id 
 Key: KAFKA-15904
 URL: https://issues.apache.org/jira/browse/KAFKA-15904
 Project: Kafka
  Issue Type: Bug
Reporter: Manikumar
 Fix For: 3.7.0


{{kafkatest.tests.core.downgrade_test.TestDowngrade}} tests are failing after 
[https://github.com/apache/kafka/pull/14628.] 
We have added {{directory.id}} to metadata.properties. This means 
{{metadata.properties}} will be different for different log directories.
Cluster downgrades will fail with below error if we have multiple log 
directories . This looks blocker or requires additional downgrade steps from AK 
3.7. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-974: Docker Image for GraalVM based Native Kafka Broker

[Manikumar]

Hi Krishna,

Thanks for KIP.  +1 (binding).


Thanks,
Manikumar

On Mon, Nov 20, 2023 at 11:57 AM Krishna Agarwal <
krishna0608agar...@gmail.com> wrote:

> Hi,
> I'd like to call a vote on KIP-974 which aims to publish a docker image for
> GraalVM based Native Kafka Broker.
>
> KIP -
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-974%3A+Docker+Image+for+GraalVM+based+Native+Kafka+Broker
>
> Discussion thread -
> https://lists.apache.org/thread/98wnx4w92fqj5wymkqlqyjsvzxz277hk
>
> Regards,
> Krishna
>

Re: [VOTE] KIP-975: Docker Image for Apache Kafka

[Manikumar]

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 26, 2023 at 9:36 PM Krishna Agarwal <
> krishna0608agar...@gmail.com> wrote:
>
> > Hi,
> > I'd like to call a vote on KIP-975 which aims to publish an official
> docker
> > image for Apache Kafka.
> >
> > KIP -
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-975%3A+Docker+Image+for+Apache+Kafka
> >
> > Discussion thread -
> > https://lists.apache.org/thread/3g43hps2dmkyxgglplrlwpsf7vkywkyy
> >
> > Regards,
> > Krishna
> >
>

Re: [DISCUSS] KIP-974 Docker Image for GraalVM based Native Kafka Broker

[Manikumar]

Thanks for the explanation. I am fine with using ""kafka-local" as the
image name.

On Fri, Oct 27, 2023 at 11:47 AM Krishna Agarwal <
krishna0608agar...@gmail.com> wrote:

> Hi Manikumar,
> Thanks for the feedback.
>
> This image signifies 2 things:
>
>1. Image should be used for the local development and testing purposes
>with fast startup times. (kafka-local)
>2. To achieve (1) - we are providing a native executable for Apache
>Kafka in the docker image. (kafka-native)
>
> While "graalvm" is the underlying tool enabling this, I'm unsure if we
> should explicitly mention it in the name.
> I'd love to hear your thoughts on this. Do you prefer "kafka-native"
> instead of "kafka-local"?
>
> Regards,
> Krishna
>
> On Fri, Oct 20, 2023 at 3:32 PM Manikumar 
> wrote:
>
> > Hi,
> >
> > > For the native AK docker image, we are considering '*kafka-local*' as
> it
> > clearly signifies that this image is intended exclusively for local
> >
> > I am not sure, if there is any naming pattern for graalvm based images.
> Can
> > we include "graalvm" to the image name like "kafka-graalvm-native".
> > This will clearly indicate this is graalvm based image.
> >
> >
> > Thanks. Regards
> >
> >
> >
> >
> > On Wed, Oct 18, 2023 at 9:26 PM Krishna Agarwal <
> > krishna0608agar...@gmail.com> wrote:
> >
> > > Hi Federico,
> > > Thanks for the feedback and apologies for the delay.
> > >
> > > I've included a section in the KIP on the release process. I would
> > greatly
> > > appreciate your insights after reviewing it.
> > >
> > > Regards,
> > > Krishna
> > >
> > > On Fri, Sep 8, 2023 at 3:08 PM Federico Valeri 
> > > wrote:
> > >
> > > > Hi Krishna, thanks for opening this discussion.
> > > >
> > > > I see you created two separate KIPs (974 and 975), but there are some
> > > > common points (build system and test plan).
> > > >
> > > > Currently, the Docker image used for system tests is only supported
> in
> > > > that limited scope, so the maintenance burden is minimal. Providing
> > > > official Kafka images would be much more complicated. Have you
> > > > considered how the image rebuild process would work in case a high
> > > > severity CVE comes out for a non Kafka image dependency? In that
> case,
> > > > there will be no Kafka release.
> > > >
> > > > Br
> > > > Fede
> > > >
> > > > On Fri, Sep 8, 2023 at 9:17 AM Krishna Agarwal
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > > I want to submit a KIP to deliver an experimental Apache Kafka
> docker
> > > > image.
> > > > > The proposed docker image can launch brokers with sub-second
> startup
> > > time
> > > > > and minimal memory footprint by leveraging a GraalVM based native
> > Kafka
> > > > > binary.
> > > > >
> > > > > KIP-974: Docker Image for GraalVM based Native Kafka Broker
> > > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-974%3A+Docker+Image+for+GraalVM+based+Native+Kafka+Broker
> > > > >
> > > > >
> > > > > Regards,
> > > > > Krishna
> > > >
> > >
> >
>

Re: [ANNOUNCE] New Kafka PMC Member: Satish Duggana

[Manikumar]

Congrats!

On Fri, Oct 27, 2023 at 8:35 PM Jun Rao  wrote:

> Hi, Everyone,
>
> Satish Duggana has been a Kafka committer since 2022. He has been very
> instrumental to the community since becoming a committer. It's my pleasure
> to announce that Satish is now a member of Kafka PMC.
>
> Congratulations Satish!
>
> Jun
> on behalf of Apache Kafka PMC
>

Re: [VOTE] KIP-978: Allow dynamic reloading of certificates with different DN / SANs

[Manikumar]

Hi,

Thanks for the KIP.

+1 (binding)


Thanks.

On Wed, Oct 25, 2023 at 1:37 AM Jakub Scholz  wrote:

> Hi all,
>
> I would like to start a vote for the KIP-978: Allow dynamic reloading of
> certificates with different DN / SANs
> <
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263429128
> >
> .
>
> Thanks & Regards
> Jakub
>

Re: [VOTE] KIP-982: Enhance Custom KafkaPrincipalBuilder to Access SslPrincipalMapper and KerberosShortNamer

[Manikumar]

Hi,

Thanks for the KIP.

+1 (binding)

Thanks,
Manikumar

On Fri, Oct 20, 2023 at 4:26 AM Raghu B  wrote:

> Hi everyone,
>
> I would like to start a vote on KIP-982, which proposed enhancements to
> the Custom KafkaPrincipalBuilder to allow access to SslPrincipalMapper and
> KerberosShortNamer.
>
> This KIP
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-982%3A+Access+SslPrincipalMapper+and+kerberosShortNamer+in+Custom+KafkaPrincipalBuilder>
> aims to improve the flexibility and usability of custom
> KafkaPrincipalBuilder implementations by enabling support for Mapping Rules
> and enhancing the overall security configuration of Kafka brokers.
>
> Thank you for your participation!
>
> Sincerely,
> Raghu
>

Re: [DISCUSS] KIP-974 Docker Image for GraalVM based Native Kafka Broker

[Manikumar]

Hi,

> For the native AK docker image, we are considering '*kafka-local*' as it
clearly signifies that this image is intended exclusively for local

I am not sure, if there is any naming pattern for graalvm based images. Can
we include "graalvm" to the image name like "kafka-graalvm-native".
This will clearly indicate this is graalvm based image.


Thanks. Regards




On Wed, Oct 18, 2023 at 9:26 PM Krishna Agarwal <
krishna0608agar...@gmail.com> wrote:

> Hi Federico,
> Thanks for the feedback and apologies for the delay.
>
> I've included a section in the KIP on the release process. I would greatly
> appreciate your insights after reviewing it.
>
> Regards,
> Krishna
>
> On Fri, Sep 8, 2023 at 3:08 PM Federico Valeri 
> wrote:
>
> > Hi Krishna, thanks for opening this discussion.
> >
> > I see you created two separate KIPs (974 and 975), but there are some
> > common points (build system and test plan).
> >
> > Currently, the Docker image used for system tests is only supported in
> > that limited scope, so the maintenance burden is minimal. Providing
> > official Kafka images would be much more complicated. Have you
> > considered how the image rebuild process would work in case a high
> > severity CVE comes out for a non Kafka image dependency? In that case,
> > there will be no Kafka release.
> >
> > Br
> > Fede
> >
> > On Fri, Sep 8, 2023 at 9:17 AM Krishna Agarwal
> >  wrote:
> > >
> > > Hi,
> > > I want to submit a KIP to deliver an experimental Apache Kafka docker
> > image.
> > > The proposed docker image can launch brokers with sub-second startup
> time
> > > and minimal memory footprint by leveraging a GraalVM based native Kafka
> > > binary.
> > >
> > > KIP-974: Docker Image for GraalVM based Native Kafka Broker
> > > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-974%3A+Docker+Image+for+GraalVM+based+Native+Kafka+Broker
> > >
> > >
> > > Regards,
> > > Krishna
> >
>

Re: [DISCUSS] KIP-975 Docker Image for Apache Kafka

[Manikumar]

Hi Krishna, Vedarth,

Thanks for the KIP.

1. Can we add directory structure of Docker Image related files in Kafka
repo.

2. > Steps for the Docker image release will be included in the Release
Process doc of Apache Kafka

Can we list down the requirements (repos, accounts) for releasing images to
docker hub. I am mainly asking because PMC needs to request docker hub
access/repos.
I can help in getting required repos/accounts.
https://infra.apache.org/docker-hub-policy.html


Thanks,
Manikumar

On Thu, Oct 19, 2023 at 8:22 PM Krishna Agarwal <
krishna0608agar...@gmail.com> wrote:

> Hi Viktor,
>
> I've noticed there are two types of custom jar configurations:
>
>1. *Type 1*: In this case, only the class name is required(e.g
> *authorizer.class.name
><http://authorizer.class.name>**)* This can be configured by the
>following steps:
>   - Mount the jar in the container.
>   - Configure the *CLASSPATH* environment variable (used by
>   *kafka-run-class.sh*) by providing the mounted path to it. This can
>   be passed as an environment variable to the docker container.
>2. *Type 2*: Here, in addition to the class name, classpath can also be
>configured (eg *remote.log.metadata.manager.class.name
><http://remote.log.metadata.manager.class.name> *and
>*remote.log.metadata.manager.class.path*). This can be configured by the
>following steps:
>   - Mount the jar in the container.
>   - Configure the respective *class.path* property.
>
> Regards,
> Krishna
>
> On Mon, Sep 25, 2023 at 11:41 PM Krishna Agarwal <
> krishna0608agar...@gmail.com> wrote:
>
> > Hi Viktor,
> > Thanks for the questions.
> >
> >1. While the docker image outlined in KIP-975 is designed for
> >production environments, it is equally suitable for development and
> testing
> >purposes. We will furnish the docker image, allowing users the
> flexibility
> >to employ it according to their specific needs.
> >2. The configs will be injected into the docker container through
> >environment variables. These environment variables will have a prefix
> >allowing for efficient parsing to extract the relevant
> properties.(Will add
> >this implementation in the KIP as well once we converge on this.)
> >3. Regarding this question, I'll conduct a test on my end after
> >gaining a better understanding, and then provide you with a response.
> >
> > Regards,
> > Krishna
> >
> >
> > On Tue, Sep 19, 2023 at 3:42 PM Viktor Somogyi-Vass
> >  wrote:
> >
> >> Hi Ismael,
> >>
> >> I'm not trying to advocate against the docker image, I just pointed out
> >> that the current scoping of the KIP may be a bit too generic and thought
> >> that KIP-974 and KIP-975 were aiming for mostly the same thing and can
> be
> >> discussed under one umbrella. Apologies if this was rooted in a
> >> misunderstanding.
> >>
> >> Kirshna,
> >>
> >> I think we need to refine the KIP a bit more. I think there are some
> >> interfaces that we need to include in the KIP as Kafka has plugins in
> >> certain cases where users are expected to provide implementation and I
> >> think it's worth discussing this in the KIP as they're kind of
> interfaces
> >> for users. Here are my questions in order:
> >> 1. In what environments do you want the image to be used? As I
> understand
> >> it would replace the current testing image and serve as a basis for
> >> development, but would it aim at production use cases too
> (docker-compose,
> >> Kubernetes, etc.)?
> >> 2. How do you plan to forward configs to the broker? Do we expect a
> >> populated server.properties file placed in a certain location or should
> >> the
> >> docker image create this file based on some input (like env vars)?
> >> 3. Certain parts can be pluggable, like metric reporters or remote log
> >> implementations that were just introduced by KIP-405. These manifest in
> >> jar
> >> files that must be put on the classpath of Kafka while certain
> classnames
> >> have to be configured. How do you plan to implement this, how do we
> >> allow users to configure such things?
> >>
> >> Thanks,
> >> Viktor
> >>
> >>
> >>
> >>
> >> On Thu, Sep 14, 2023 at 4:59 PM Kenneth Eversole
> >>  wrote:
> >>
> >> > Hello,
> >> >
> >> > I think this would be a wonderful improvement to the ecosystem. While
> >> > Vikt

Re: [DISCUSS] KIP-982: Access SslPrincipalMapper and kerberosShortNamer in Custom KafkaPrincipalBuilder

[Manikumar]

Hi Raghu,

Thanks for the KIP. Proposed changes look good to me.

Thanks,
Manikumar

On Fri, Sep 22, 2023 at 11:44 PM Raghu B  wrote:

> Hi everyone,
>
> I would like to start the discussion on the KIP-982 to Access
> SslPrincipalMapper and kerberosShortNamer in Custom KafkaPrincipalBuilder
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-982%3A+Access+SslPrincipalMapper+and+kerberosShortNamer+in+Custom+KafkaPrincipalBuilder
>
> Looking forward to your feedback!
>
> Thanks,
> Raghu
>

[jira] [Resolved] (KAFKA-14927) Dynamic configs not validated when using kafka-configs and --add-config-file

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-14927.
---
Fix Version/s: 3.7.0
 Assignee: Aman Singh  (was: José Armando García Sancio)
   Resolution: Fixed

> Dynamic configs not validated when using kafka-configs and --add-config-file
> 
>
> Key: KAFKA-14927
> URL: https://issues.apache.org/jira/browse/KAFKA-14927
> Project: Kafka
>  Issue Type: Bug
>  Components: tools
>Affects Versions: 3.3.2
>Reporter: Justin Daines
>Assignee: Aman Singh
>Priority: Minor
>  Labels: 4.0-blocker
> Fix For: 3.7.0
>
>
> Using {{kafka-configs}} should validate dynamic configurations before 
> applying. It is possible to send a file with invalid configurations. 
> For example a file containing the following:
> {code:java}
> {
>   "routes": {
>     "crn:///kafka=*": {
>       "management": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events-denied"
>       },
>       "describe": {
>         "allowed": "",
>         "denied": "confluent-audit-log-events-denied"
>       },
>       "authentication": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events-denied-authn"
>       },
>       "authorize": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events-denied-authz"
>       },
>       "interbroker": {
>         "allowed": "",
>         "denied": ""
>       }
>     },
>     "crn:///kafka=*/group=*": {
>       "consume": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events"
>       }
>     },
>     "crn:///kafka=*/topic=*": {
>       "produce": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events"
>       },
>       "consume": {
>         "allowed": "confluent-audit-log-events_audit",
>         "denied": "confluent-audit-log-events"
>       }
>     }
>   },
>   "destinations": {
>     "topics": {
>       "confluent-audit-log-events": {
>         "retention_ms": 777600
>       },
>       "confluent-audit-log-events-denied": {
>         "retention_ms": 777600
>       },
>       "confluent-audit-log-events-denied-authn": {
>         "retention_ms": 777600
>       },
>       "confluent-audit-log-events-denied-authz": {
>         "retention_ms": 777600
>       },
>       "confluent-audit-log-events_audit": {
>         "retention_ms": 777600
>       }
>     }
>   },
>   "default_topics": {
>     "allowed": "confluent-audit-log-events_audit",
>     "denied": "confluent-audit-log-events"
>   },
>   "excluded_principals": [
>     "User:schemaregistryUser",
>     "User:ANONYMOUS",
>     "User:appSA",
>     "User:admin",
>     "User:connectAdmin",
>     "User:connectorSubmitter",
>     "User:connectorSA",
>     "User:schemaregistryUser",
>     "User:ksqlDBAdmin",
>     "User:ksqlDBUser",
>     "User:controlCenterAndKsqlDBServer",
>     "User:controlcenterAdmin",
>     "User:restAdmin",
>     "User:appSA",
>     "User:clientListen",
>     "User:superUser"
>   ]
> } {code}
> {code:java}
> kafka-configs --bootstrap-server $KAFKA_BOOTSTRAP --entity-type brokers 
> --entity-default --alter --add-config-file audit-log.json {code}
> Yields the following dynamic configs:
> {code:java}
> Default configs for brokers in the cluster are:
>   "destinations"=null sensitive=true 
> synonyms={DYNAMIC_DEFAULT_BROKER_CONFIG:"destinations"=null}
>   "confluent-audit-log-events-denied-auth

[jira] [Resolved] (KAFKA-15502) Handle large keystores in SslEngineValidator

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15502.
---
Fix Version/s: 3.4.2
   3.5.2
   3.7.0
   3.6.1
   Resolution: Fixed

> Handle large keystores in SslEngineValidator
> 
>
> Key: KAFKA-15502
> URL: https://issues.apache.org/jira/browse/KAFKA-15502
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Manikumar
>    Assignee: Manikumar
>Priority: Major
> Fix For: 3.4.2, 3.5.2, 3.7.0, 3.6.1
>
>
> We have observed an issue where inter broker SSL listener is not coming up 
> for large keystores (size >16K)
> 1. Currently validator code doesn't work well with large stores. Right now, 
> WRAP returns if there is already data in the buffer. But if we need more data 
> to be wrapped for UNWRAP to succeed, we end up looping forever.
> 2. Observed large TLSv3 post handshake messages are not getting read and 
> causing validator code loop forever. This is observed with JDK17+
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15502) Handle large keystores in SslEngineValidator

[Manikumar (Jira)]

Manikumar created KAFKA-15502:
-

 Summary: Handle large keystores in SslEngineValidator
 Key: KAFKA-15502
 URL: https://issues.apache.org/jira/browse/KAFKA-15502
 Project: Kafka
  Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Manikumar
Assignee: Manikumar


We have observed an issue where inter broker SSL listener is not coming up for 
large keystores (size >16K)

1. Currently validator code doesn't work well with large stores. Right now, 
WRAP returns if there is already data in the buffer. But if we need more data 
to be wrapped for UNWRAP to succeed, we end up looping forever.

2. Observed large TLSv3 post handshake messages are not getting read and 
causing UNWRAP loop forever. This is observed with JDK17+
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15273) Log common name of expired client certificate

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15273.
---
Fix Version/s: 3.7.0
   Resolution: Fixed

> Log common name of expired client certificate
> -
>
> Key: KAFKA-15273
> URL: https://issues.apache.org/jira/browse/KAFKA-15273
> Project: Kafka
>  Issue Type: Improvement
>  Components: clients, core, security
>Affects Versions: 3.6.0
>Reporter: Eike Thaden
>Assignee: Eike Thaden
>Priority: Minor
>  Labels: PatchAvailable
> Fix For: 3.7.0
>
>
> If a client tries to authenticate via mTLS with an expired certificate, the 
> connection is closed and the IP address of the connection attempt is logged. 
> However, in complex enterprise IT environments it might be very hard or even 
> impossible to identify which client tried to connect if only the IP address 
> is known (e.g. due to complex virtualization/containerization/NAT). This 
> results in significant effort for the Kafka platform teams to identify the 
> developmers responsible for such a misconfigured client.
> As a possible solution I propose to log the common name used in the client 
> certificate in addition to the IP address. Due to security considerations, 
> this should only be done if that certificate is just expired and would be 
> valid otherwise (e.g. signed by a known, non-expired root/intermediate CA). 
> The way Kafka should handle any valid/invalid/expired certificate must be 
> exactly the same as before, except for the creation of a log message in case 
> it is expired.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15243) User creation mismatch

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15243.
---
Fix Version/s: 3.6.0
   Resolution: Fixed

> User creation mismatch
> --
>
> Key: KAFKA-15243
> URL: https://issues.apache.org/jira/browse/KAFKA-15243
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.2
>Reporter: Sergio Troiano
>Assignee: Sergio Troiano
>Priority: Major
>  Labels: kafka-source
> Fix For: 3.6.0
>
>
> We found the Kafka users were not created properly, so let's suppose we 
> create the user [myu...@myuser.com|mailto:myu...@myuser.com]
>  
> COMMAND:
> {code:java}
> /etc/new_kafka/bin/kafka-configs.sh  --bootstrap-server localhost:9092 
> --alter --add-config 
> 'SCRAM-SHA-256=[iterations=4096,password=blabla],SCRAM-SHA-256=[password=blabla]'
>  --entity-type users --entity-name myu...@myuser.com{code}
> RESPONSE:
> {code:java}
> Completed updating config for user myu...@myuser.com{code}
> When listing the users I see the user was created as an encoded string
> COMMAND
> {code:java}
> kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type 
> users|grep myuser {code}
> RESPONSE
> {code:java}
> SCRAM credential configs for user-principal 'myuser%40myuser.com' are 
> SCRAM-SHA-256=iterations=8192, SCRAM-SHA-512=iterations=4096 {code}
>  
> So basically the user is being "sanitized" and giving a false OK to the user 
> requester. The user requested does not exist as it should, it creates the 
> encoded one instead.
>  
> I dug deep in the code until I found this is happening in the 
> ZkAdminManager.scala in this line 
>  
> {code:java}
> adminZkClient.changeConfigs(ConfigType.User, Sanitizer.sanitize(user), 
> configsByPotentiallyValidUser(user)) {code}
> So removing the Sanitizer fix the problem, but I have a couple of doubts
> I checked we Sanitize because of some JMX metrics, but in this case I don't 
> know if this is really needed, supossing this is needed I think we should 
> forbid to create users with characters that will be encoded.
> Even worse after creating an user in general we create ACLs and they are 
> created properly without encoding the characters, this creates a mismatch 
> between the user and the ACLs.
>  
>  
> So I can work on fixing this, but I think we need to decide :
>  
> A) We forbid to create users with characters that will be encoded, so we fail 
> in the user creation step.
>  
> B) We allow the user creation with special characters and remove the 
> Sanitizer.sanitize(user) from the 2 places where it shows up in the file 
> ZkAdminManager.scala
>  
>  
> And of course if we go for B we need to create the tests.
> Please let me know what you think and i can work on it



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-15077) FileTokenRetriever doesn't trim the token before returning it.

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-15077.
---
Resolution: Fixed

> FileTokenRetriever doesn't trim the token before returning it.
> --
>
> Key: KAFKA-15077
> URL: https://issues.apache.org/jira/browse/KAFKA-15077
> Project: Kafka
>  Issue Type: Bug
>  Components: clients
>Reporter: Sushant Mahajan
>Assignee: Sushant Mahajan
>Priority: Minor
> Fix For: 3.6.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The {{FileTokenRetriever}} class is used to read the access_token from a file 
> on the clients system and then the info is passed along with jaas config to 
> the {{{}OAuthBearerSaslServer{}}}.
> The server uses the class {{OAuthBearerClientInitialResponse}} to validate 
> the token format.
> In case the token was sent using {{FileTokenRetriever}} on the client side, 
> some EOL character is getting appended to the token, causing authentication 
> to fail with the message (in case to topic create):
>  {{ERROR org.apache.kafka.common.errors.SaslAuthenticationException: 
> Authentication failed during authentication due to invalid credentials with 
> SASL mechanism OAUTHBEARER}}
>  
> On the server side the following line 
> [https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/oauthbearer/internals/OAuthBearerClientInitialResponse.java#L68]
>  with throw an exception failing the request.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New Kafka PMC Member: David Arthur

[Manikumar]

Congrats David!


On Fri, Mar 10, 2023 at 12:24 AM Josep Prat 
wrote:
>
> Congrats David!
>
> ———
> Josep Prat
>
> Aiven Deutschland GmbH
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> m: +491715557497
>
> w: aiven.io
>
> e: josep.p...@aiven.io
>
> On Thu, Mar 9, 2023, 19:22 Mickael Maison 
wrote:
>
> > Congratulations David!
> >
> > On Thu, Mar 9, 2023 at 7:20 PM Chris Egerton 
> > wrote:
> > >
> > > Congrats David!
> > >
> > > On Thu, Mar 9, 2023 at 1:17 PM Bill Bejeck  wrote:
> > >
> > > > Congratulations David!
> > > >
> > > > On Thu, Mar 9, 2023 at 1:12 PM Jun Rao 
> > wrote:
> > > >
> > > > > Hi, Everyone,
> > > > >
> > > > > David Arthur has been a Kafka committer since 2013. He has been
very
> > > > > instrumental to the community since becoming a committer. It's my
> > > > pleasure
> > > > > to announce that David is now a member of Kafka PMC.
> > > > >
> > > > > Congratulations David!
> > > > >
> > > > > Jun
> > > > > on behalf of Apache Kafka PMC
> > > > >
> > > >
> >

Re: [ANNOUNCE] New Kafka PMC Member: Chris Egerton

[Manikumar]

Congrats Chris!. Well deserved.

On Fri, Mar 10, 2023 at 12:23 AM Josep Prat  wrote:
>
> Congrats Chris!
>
> ———
> Josep Prat
>
> Aiven Deutschland GmbH
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> m: +491715557497
>
> w: aiven.io
>
> e: josep.p...@aiven.io
>
> On Thu, Mar 9, 2023, 19:22 Mickael Maison  wrote:
>
> > Congratulations Chris!
> >
> > On Thu, Mar 9, 2023 at 7:17 PM Bill Bejeck  wrote:
> > >
> > > Congratulations Chris!
> > >
> > > On Thu, Mar 9, 2023 at 1:12 PM Jun Rao  wrote:
> > >
> > > > Hi, Everyone,
> > > >
> > > > Chris Egerton has been a Kafka committer since July 2022. He has been
> > very
> > > > instrumental to the community since becoming a committer. It's my
> > pleasure
> > > > to announce that Chris is now a member of Kafka PMC.
> > > >
> > > > Congratulations Chris!
> > > >
> > > > Jun
> > > > on behalf of Apache Kafka PMC
> > > >
> >

Re: [VOTE] KIP-900: KRaft kafka-storage.sh API additions to support SCRAM for Kafka Brokers

[Manikumar]

+1 (binding)

Thanks for the KIP.

On Wed, Feb 22, 2023 at 3:48 AM José Armando García Sancio
 wrote:
>
> LGTM Proven. Thanks for the improvements. +1 (binding)
>
> --
> -José

Re: [Possible bug] Failing to use multiple client for multiple cluster using SASL channel.

[Manikumar]

Hi Sourav,

Can you check if https://github.com/apache/kafka/pull/13211 can help
to handle your scenario?.

Thanks

On Sun, Feb 5, 2023 at 6:23 AM Sourav Biswas
 wrote:
>
> Hello Kafka Dev,
> Issue:Say, I need to configure multiple client (consumer/producer) listening 
> and publishing to different cluster inside same application (Same JVM). Both 
> cluster uses
> - sasl.mechanism = GSSAPI- security.porotocol = SASL_PLAINTEXT
>
> But, different 'sasl.kerberos.service.name'.
>
> Now, considering above configuration, client will create a KafkaChannel using 
> SaslChannelBuilder, which uses a 
> LoginManager.https://github.com/apache/kafka/blob/4a7fedd46a7fc1eff5411a0f4329781c9474f8e8/clients/src/main/java/org/apache/kafka/common/network/SaslChannelBuilder.java#L170
> For this case, it should create multiple LoginManager for each cluster but it 
> is creating only one. Because of this Authentication is failing for all 
> cluster except one.
>
> Reason:
> A static Map of login managers is maintained, with key of LoginMetadata
>STATIC_INSTANCES.put(loginMetadata, loginManager);
>
> - 
> https://github.com/apache/kafka/blob/4a7fedd46a7fc1eff5411a0f4329781c9474f8e8/clients/src/main/java/org/apache/kafka/common/security/authenticator/LoginManager.java#L109
>
> - 
> https://github.com/apache/kafka/blob/4a7fedd46a7fc1eff5411a0f4329781c9474f8e8/clients/src/main/java/org/apache/kafka/common/security/authenticator/LoginManager.java#L113
>
> LoginMetadata only considers following fields to maintains its uniqueness.
> final T configInfo; // "KafkaClient"; Same for all cluster
> final Class loginClass; // Same for all clusester
> final Class 
> loginCallbackClass; // Same for all cluster
>
>
> Possible fix:Need to consider more fields ( 
> sasl.kerberos.service.name/client.id/somethin-else) to maintain more granular 
> uniqueness.
>
> Note:If you feel it's a bug, then I can raise a PR if I get a jira. Please 
> share your thoughts.
> ~ Sourav
>
>

CVE-2023-25194: Apache Kafka: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration using Kafka Connect

[Manikumar]

Severity: important

Description:

A possible security vulnerability has been identified in Apache Kafka
Connect. This requires access to a Kafka Connect worker,
and the ability to create/modify connectors on it with an arbitrary
Kafka client SASL JAAS config and a SASL-based security protocol,
which has been possible on Kafka Connect clusters since Apache Kafka
2.3.0. When configuring the connector via the Kafka Connect REST API,
an authenticated operator can set the `sasl.jaas.config` property for any
of the connector's Kafka clients to
"com.sun.security.auth.module.JndiLoginModule",
which can be done via the `producer.override.sasl.jaas.config`,
`consumer.override.sasl.jaas.config`, or
`admin.override.sasl.jaas.config` properties.

This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to
execute java deserialization gadget chains on the Kafka connect
server. Attackers can cause unrestricted deserialization of untrusted
data (or) RCE vulnerability when there are gadgets in the classpath.

Since Apache Kafka 3.0.0, users are allowed to specify these properties
in connector configurations for Kafka Connect clusters running with
out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not
specify these properties unless the Kafka Connect cluster has been reconfigured
with a connector client override policy that permits them.

Since Apache Kafka 3.4.0, we have added a system property
("-Dorg.apache.kafka.disallowed.login.modules") to disable the
problematic login modules usage in SASL JAAS configuration. Also by
default "com.sun.security.auth.module.JndiLoginModule" is disabled
in Apache Kafka 3.4.0.

We advise the Kafka Connect users to validate connector configurations
and only allow trusted JNDI configurations. Also examine connector
dependencies for vulnerable versions and either upgrade their
connectors, upgrading that specific dependency, or removing the
connectors as options for remediation. Finally, in addition to leveraging the
"org.apache.kafka.disallowed.login.modules" system property, Kafka Connect users
can also implement their own connector client config override policy, which can
be used to control which Kafka client properties can be overridden directly
in a connector config and which cannot.

Credit:

Apache Kafka would like to thank Jari Jääskelä
(https://hackerone.com/reports/1529790)
and 4ra1n and Y4tacker (they found vulnerabilities in other Apache projects.
After discussion between PMC of the two projects, it was finally
confirmed that it was the vulnerability of Kafka then they reported it to us)


References:

https://kafka.apache.org/cve-list
https://kafka.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-25194

Re: [VOTE] 3.3.2 RC1

[Manikumar]

Hi Chris,

+1 (binding)

- verified the signatures, artifacts
- ran the tests on the source archive
- verified the quickstarts

Thanks for running the release!

Thanks,
Manikumar


On Fri, Dec 23, 2022 at 4:44 PM Federico Valeri  wrote:
>
> Hi, I did the following to validate the release:
>
> - Checksums and signatures ok
> - Build from source using Java 17 and Scala 2.13 ok
> - Unit and integration tests ok
> - Quickstart in both ZK and KRaft modes ok
> - Test app with staging Maven artifacts ok
>
> +1 (non binding)
>
> Thanks
> Fede
>
> On Wed, Dec 21, 2022 at 11:21 PM Chris Egerton  
> wrote:
> >
> > Hello Kafka users, developers and client-developers,
> >
> > This is the second candidate for release of Apache Kafka 3.3.2.
> >
> > This is a bugfix release with several fixes since the release of 3.3.1. A
> > few of the major issues include:
> >
> > * KAFKA-14358 Users should not be able to create a regular topic name
> > __cluster_metadata
> > KAFKA-14379 Consumer should refresh preferred read replica on update
> > metadata
> > * KAFKA-13586 Prevent exception thrown during connector update from
> > crashing distributed herder
> >
> >
> > Release notes for the 3.3.2 release:
> > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/RELEASE_NOTES.html
> >
> > *** Please download, test and vote by Friday, January 6, 2023, 10pm UTC
> > (this date is chosen to accommodate the various upcoming holidays that
> > members of the community will be taking and give everyone enough time to
> > test out the release candidate, without unduly delaying the release)
> >
> > Kafka's KEYS file containing PGP keys we use to sign the release:
> > https://kafka.apache.org/KEYS
> >
> > * Release artifacts to be voted upon (source and binary):
> > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/
> >
> > * Maven artifacts to be voted upon:
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >
> > * Javadoc:
> > https://home.apache.org/~cegerton/kafka-3.3.2-rc1/javadoc/
> >
> > * Tag to be voted upon (off 3.3 branch) is the 3.3.2 tag:
> > https://github.com/apache/kafka/releases/tag/3.3.2-rc1
> >
> > * Documentation:
> > https://kafka.apache.org/33/documentation.html
> >
> > * Protocol:
> > https://kafka.apache.org/33/protocol.html
> >
> > The most recent build has had test failures. These all appear to be due to
> > flakiness, but it would be nice if someone more familiar with the failed
> > tests could confirm this. I may update this thread with passing build links
> > if I can get one, or start a new release vote thread if test failures must
> > be addressed beyond re-running builds until they pass.
> >
> > Unit/integration tests:
> > https://ci-builds.apache.org/job/Kafka/job/kafka/job/3.3/142/testReport/
> >
> > José, would it be possible to re-run the system tests for 3.3 on the latest
> > commit for 3.3 (e3212f2), and share the results on this thread?
> >
> > Cheers,
> >
> > Chris

Re: [ANNOUNCE] New committer: Satish Duggana

[Manikumar]

Congrats, Satish!  Well deserved.

On Sat, Dec 24, 2022, 5:10 PM Tom Bentley  wrote:

> Congratulations!
>
> On Sat, 24 Dec 2022 at 05:05, Luke Chen  wrote:
>
> > Congratulations, Satish!
> >
> > On Sat, Dec 24, 2022 at 4:12 AM Federico Valeri 
> > wrote:
> >
> > > Hi Satish, congrats!
> > >
> > > On Fri, Dec 23, 2022, 8:46 PM Viktor Somogyi-Vass
> > >  wrote:
> > >
> > > > Congrats Satish!
> > > >
> > > > On Fri, Dec 23, 2022, 19:38 Mickael Maison  >
> > > > wrote:
> > > >
> > > > > Congratulations Satish!
> > > > >
> > > > > On Fri, Dec 23, 2022 at 7:36 PM Divij Vaidya <
> > divijvaidy...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Congratulations Satish! 
> > > > > >
> > > > > > On Fri 23. Dec 2022 at 19:32, Josep Prat
> >  > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Congrats Satish!
> > > > > > >
> > > > > > > ———
> > > > > > > Josep Prat
> > > > > > >
> > > > > > > Aiven Deutschland GmbH
> > > > > > >
> > > > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > > > > <
> > > > >
> > > >
> > >
> >
> https://www.google.com/maps/search/Immanuelkirchstra%C3%9Fe+26,+10405+Berlin?entry=gmail=g
> > > > > >
> > > > > > >
> > > > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > > > >
> > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > > > >
> > > > > > > m: +491715557497
> > > > > > >
> > > > > > > w: aiven.io
> > > > > > >
> > > > > > > e: josep.p...@aiven.io
> > > > > > >
> > > > > > > On Fri, Dec 23, 2022, 19:23 Chris Egerton <
> > fearthecel...@gmail.com
> > > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Congrats, Satish!
> > > > > > > >
> > > > > > > > On Fri, Dec 23, 2022, 13:19 Arun Raju 
> > > > wrote:
> > > > > > > >
> > > > > > > > > Congratulations 
> > > > > > > > >
> > > > > > > > > On Fri, Dec 23, 2022, 1:08 PM Jun Rao
> >  > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi, Everyone,
> > > > > > > > > >
> > > > > > > > > > The PMC of Apache Kafka is pleased to announce a new
> Kafka
> > > > > committer
> > > > > > > > > Satish
> > > > > > > > > > Duggana.
> > > > > > > > > >
> > > > > > > > > > Satish has been a long time Kafka contributor since 2017.
> > He
> > > is
> > > > > the
> > > > > > > > main
> > > > > > > > > > driver behind KIP-405 that integrates Kafka with remote
> > > > storage,
> > > > > a
> > > > > > > > > > significant and much anticipated feature in Kafka.
> > > > > > > > > >
> > > > > > > > > > Congratulations, Satish!
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > Jun (on behalf of the Apache Kafka PMC)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > --
> > > > > > Divij Vaidya
> > > > >
> > > >
> > >
> >
>

[jira] [Resolved] (KAFKA-14320) Upgrade Jackson for CVE fix

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-14320.
---
Resolution: Fixed

> Upgrade Jackson for CVE fix
> ---
>
> Key: KAFKA-14320
> URL: https://issues.apache.org/jira/browse/KAFKA-14320
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.2.0
>Reporter: Javier Li Sam
>Assignee: Thomas Cooper
>Priority: Minor
>  Labels: security
> Fix For: 3.4.0, 3.3.2
>
>
> There is a CVE for Jackson:
> Jackson: [CVE-2020-36518|https://nvd.nist.gov/vuln/detail/CVE-2020-36518] - 
> Fixed by upgrading to 2.14.0+



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-13518) Update gson dependency

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-13518.
---
Fix Version/s: 3.4.0
   Resolution: Fixed

> Update gson dependency
> --
>
> Key: KAFKA-13518
> URL: https://issues.apache.org/jira/browse/KAFKA-13518
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.0.0
>Reporter: Pavel Kuznetsov
>Assignee: Dongjin Lee
>Priority: Major
>  Labels: security
> Fix For: 3.4.0
>
>
> *Describe the bug*
> I checked kafka_2.13-3.0.0.tgz distribution with WhiteSource and find out 
> that some libraries have vulnerabilities.
> Here they are:
> * gson-2.8.6.jar has WS-2021-0419 vulnerability. The way to fix it is to 
> upgrade to com.google.code.gson:gson:2.8.9
> * netty-codec-4.1.65.Final.jar has CVE-2021-37136 and CVE-2021-37137 
> vulnerabilities. The way to fix it is to upgrade to 
> io.netty:netty-codec:4.1.68.Final
> *To Reproduce*
> Download kafka_2.13-3.0.0.tgz and find jars, listed above.
> Check that these jars with corresponding versions are mentioned in 
> corresponding vulnerability description.
> *Expected behavior*
> * gson upgraded to 2.8.9 or higher
> * netty-codec upgraded to 4.1.68.Final or higher
> *Actual behaviour*
> * gson is 2.8.6
> * netty-codec is 4.1.65.Final



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: PR for CVE-2022-34917

[Manikumar]

https://issues.apache.org/jira/browse/KAFKA-14063?focusedCommentId=17608137=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17608137

On Mon, Sep 26, 2022 at 7:42 PM Swathi Mocharla
 wrote:
>
> Hi,
> CVE: https://nvd.nist.gov/vuln/detail/CVE-2022-34917
> Could you please help with the PR that fixed this vulnerability? We are
> looking to apply the patch that fixes this and we are unable to find it.
> Thanks,
> Swathi

[jira] [Resolved] (KAFKA-14212) Fetch error response when hitting public OAuth/OIDC provider

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-14212.
---
Fix Version/s: 3.4.0
   Resolution: Fixed

> Fetch error response when hitting public OAuth/OIDC provider
> 
>
> Key: KAFKA-14212
> URL: https://issues.apache.org/jira/browse/KAFKA-14212
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Sushant Mahajan
>Assignee: Sushant Mahajan
>Priority: Minor
> Fix For: 3.4.0
>
>
> The class 
> org.apache.kafka.common.security.oauthbearer.secured.HttpAccessTokenRetriever 
> is used to send client creds to public OAuth/OIDC provider and fetch the 
> response, possibly including the access token.
> However, if there is an error - the exact error message from the provider is 
> not currently being retrieved.
> The error message can help the client easily diagnose if failure to fetch 
> token is due to some misconfiguration on their side.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (KAFKA-14063) Kafka message parsing can cause ooms with small antagonistic payloads

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-14063.
---
Resolution: Fixed

> Kafka message parsing can cause ooms with small antagonistic payloads
> -
>
> Key: KAFKA-14063
> URL: https://issues.apache.org/jira/browse/KAFKA-14063
> Project: Kafka
>  Issue Type: Bug
>  Components: generator
>Affects Versions: 3.2.0
>Reporter: Daniel Collins
>Priority: Major
> Fix For: 2.8.2, 3.2.3, 3.1.2, 3.0.2
>
>
> When parsing code receives a payload for a variable length field where the 
> length is specified in the code as some arbitrarily large number (assume 
> INT32_MAX for example) this will immediately try to allocate an ArrayList to 
> hold this many elements, before checking whether this is a reasonable array 
> size given the available data. 
> The fix for this is to instead throw a runtime exception if the length of a 
> variably sized container exceeds the amount of remaining data. Then, the 
> worst a user can do is force the server to allocate 8x the size of the actual 
> delivered data (if they claim there are N elements for a container of Objects 
> (i.e. not a byte string) and each Object bottoms out in an 8 byte pointer in 
> the ArrayList's backing array).
> This was identified by fuzzing the kafka request parsing code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

CVE-2022-34917: Unauthenticated clients may cause OutOfMemoryError on Apache Kafka Brokers

[Manikumar]

Severity: High

Description:

A security vulnerability has been identified in Apache Kafka. It
affects all releases since 2.8.0. The vulnerability allows malicious
unauthenticated clients to allocate large amounts of memory on
brokers. This can lead to brokers hitting OutOfMemoryException and
causing denial of service.

Example scenarios:
- Kafka cluster without authentication: Any clients able to establish
a network connection to a broker can trigger the issue.
- Kafka cluster with SASL authentication: Any clients able to
establish a network connection to a broker, without the need for valid
SASL credentials, can trigger the issue.
- Kafka cluster with TLS authentication: Only clients able to
successfully authenticate via TLS can trigger the issue.

We advise the users to upgrade the Kafka installations to one of the
3.2.3, 3.1.2, 3.0.2, 2.8.2 versions.

Credit:

Apache Kafka would like to thank Mickael Maison, Tom Bentley and
Daniel Collins for reporting this issue.

References:

https://kafka.apache.org/cve-list

CVE-2022-34917: Unauthenticated clients may cause OutOfMemoryError on Apache Kafka Brokers

[Manikumar]

Severity: High

Description:

A security vulnerability has been identified in Apache Kafka. It
affects all releases since 2.8.0. The vulnerability allows malicious
unauthenticated clients to allocate large amounts of memory on
brokers. This can lead to brokers hitting OutOfMemoryException and
causing denial of service.

Example scenarios:
- Kafka cluster without authentication: Any clients able to establish
a network connection to a broker can trigger the issue.
- Kafka cluster with SASL authentication: Any clients able to
establish a network connection to a broker, without the need for valid
SASL credentials, can trigger the issue.
- Kafka cluster with TLS authentication: Only clients able to
successfully authenticate via TLS can trigger the issue.

We advise the users to upgrade the Kafka installations to one of the
3.2.3, 3.1.2, 3.0.2, 2.8.2 versions.

Credit:

Apache Kafka would like to thank Mickael Maison, Tom Bentley and
Daniel Collins for reporting this issue.

References:

https://kafka.apache.org/cve-list

[ANNOUNCE] Apache Kafka 3.2.3

[Manikumar]

The Apache Kafka community is pleased to announce the release for
Apache Kafka 3.2.3

Apache Kafka 3.2.3 is a bugfix release and it contains important
security fixes. This also fixes 7 issues since the 3.2.1
release. Please see the release notes for more information.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/3.2.3/RELEASE_NOTES.html


You can download the source and binary release (Scala 2.12 and 2.13) from:
https://kafka.apache.org/downloads#3.2.3

---


Apache Kafka is a distributed streaming platform with four core APIs:


** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of application:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 12 contributors to this release!

Andrew Borley, Andrew Dean, Colin Patrick McCabe, David Arthur, Derek
Troy-West, Divij Vaidya, Jason Gustafson, Manikumar Reddy, Mickael
Maison, Philip Nee, Thomas Cooper, Tom Bentley

Thanks to Mickael Maison and Tom Bentley for driving this release.

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Apache Kafka PMC

[ANNOUNCE] Apache Kafka 3.1.2

[Manikumar]

The Apache Kafka community is pleased to announce the release for
Apache Kafka 3.1.2

Apache Kafka 3.1.2 is a bugfix release and it contains important
security fixes. It also fixes 4 issues since the 3.1.1
release. Please see the release notes for more information.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/3.1.2/RELEASE_NOTES.html


You can download the source and binary release (Scala 2.12 and 2.13) from:
https://kafka.apache.org/downloads#3.1.2

---


Apache Kafka is a distributed streaming platform with four core APIs:


** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of application:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 16 contributors to this release!

Andrew Borley, Bruno Cadonna, Colin Patrick McCabe, David Jacot, Derek
Troy-West, Divij Vaidya, Guozhang Wang, Ismael Juma, Jason Gustafson,
Kirk True, Lucas Bradstreet, Manikumar Reddy, Mickael Maison,
nicolasguyomar, Niket, Tom Bentley

Thanks to Mickael Maison and Tom Bentley for driving this release.

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Apache Kafka PMC

[ANNOUNCE] Apache Kafka 3.0.2

[Manikumar]

The Apache Kafka community is pleased to announce the release for Apache
Kafka 3.0.2

Apache Kafka 3.0.2 is a bugfix release and it contains important
security fixes. It also fixes 10 issues since the 3.0.1
release. Please see the release notes for more information.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/3.0.2/RELEASE_NOTES.html


You can download the source and binary release (Scala 2.12 and 2.13) from:
https://kafka.apache.org/downloads#3.0.2

---


Apache Kafka is a distributed streaming platform with four core APIs:


** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of application:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 22 contributors to this release!

Andrew Borley, Bounkong Khamphousone, Colin Patrick McCabe, David Jacot,
Derek Troy-West, Ismael Juma, Jason Gustafson, Jules Ivanic, Justine
Olshan, Konstantine Karantasis, Lucas Bradstreet, Manikumar Reddy, Mickael
Maison, nicolasguyomar, Niket, Philip Nee, Randall Hauch, Stanislav
Vodetskyi, Tom Bentley, Vincent Jiang, Xiaoyue Xue, Yang Yu

Thanks to Tom Bentley for driving this release.

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Apache Kafka PMC

[ANNOUNCE] Apache Kafka 2.8.2

[Manikumar]

The Apache Kafka community is pleased to announce the release for Apache
Kafka 2.8.2

Apache Kafka 2.8.2 is a bugfix release and it contains important
security fixes. It also fixes 11 issues since the 2.8.1
release. Please see the release notes for more information.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html


You can download the source and binary release (Scala 2.12 and 2.13) from:
https://kafka.apache.org/downloads#2.8.2

---


Apache Kafka is a distributed streaming platform with four core APIs:


** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of application:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 17 contributors to this release!

A. Sophie Blee-Goldman, Andrew Borley, Bruno Cadonna, Colin Patrick McCabe,
David Jacot, Jason Gustafson, jiangyuan, Justine Olshan, Luke Chen,
Manikumar Reddy, Matthias J. Sax, Oliver Hutchison, Philip Nee, Prateek
Agarwal, prince-mahajan, Randall Hauch, Stanislav Vodetskyi

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Manikumar

[jira] [Resolved] (KAFKA-13730) OAuth access token validation fails if it does not contain the "sub" claim

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-13730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-13730.
---
Fix Version/s: 3.4.0
   Resolution: Fixed

> OAuth access token validation fails if it does not contain the "sub" claim
> --
>
> Key: KAFKA-13730
> URL: https://issues.apache.org/jira/browse/KAFKA-13730
> Project: Kafka
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 3.1.0
>Reporter: Daniel Fonai
>Assignee: Kirk True
>Priority: Minor
> Fix For: 3.4.0
>
>
> Client authentication fails, when configured to use OAuth and the JWT access 
> token does {*}not contain the sub claim{*}. This issue was discovered while 
> testing Kafka integration with Ping Identity OAuth server. According to 
> Ping's 
> [documentation|https://apidocs.pingidentity.com/pingone/devguide/v1/api/#access-tokens-and-id-tokens]:
> {quote}sub – A string that specifies the identifier for the authenticated 
> user. This claim is not present for client_credentials tokens.
> {quote}
> In this case Kafka broker rejects the token regardless of the 
> [sasl.oauthbearer.sub.claim.name|https://kafka.apache.org/documentation/#brokerconfigs_sasl.oauthbearer.sub.claim.name]
>  property value.
>  
> 
>  
> Steps to reproduce:
> 1. Client configuration:
> {noformat}
> security.protocol=SASL_PLAINTEXT
> sasl.mechanism=OAUTHBEARER
> sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandler
> sasl.oauthbearer.token.endpoint.url=https://oauth.server.fqdn/token/endpoint
> sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule
>  required\
>  clientId="kafka-client"\
>  clientSecret="kafka-client-secret";
> sasl.oauthbearer.sub.claim.name=client_id # claim name for the principal to 
> be extracted from, needed for client side validation too
> {noformat}
> 2. Broker configuration:
> {noformat}
> sasl.enabled.mechanisms=...,OAUTHBEARER
> listener.name.sasl_plaintext.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule
>  required;
> listener.name.sasl_plaintext.oauthbearer.sasl.server.callback.handler.class=org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler
> sasl.oauthbearer.jwks.endpoint.url=https://oauth.server.fqdn/jwks/endpoint
> sasl.oauthbearer.expected.audience=oauth-audience # based on OAuth server 
> setup
> sasl.oauthbearer.sub.claim.name=client_id # claim name for the principal to 
> be extracted from
> {noformat}
> 3. Try to perform some client operation:
> {noformat}
> kafka-topics --bootstrap-server `hostname`:9092 --list --command-config 
> oauth-client.properties
> {noformat}
> Result:
> Client authentication fails due to invalid access token.
>  - client log:
> {noformat}
> [2022-03-11 16:21:20,461] ERROR [AdminClient clientId=adminclient-1] 
> Connection to node -1 (localhost/127.0.0.1:9092) failed authentication due 
> to: {"status":"invalid_token"} (org.apache.kafka.clients.NetworkClient)
> [2022-03-11 16:21:20,463] WARN [AdminClient clientId=adminclient-1] Metadata 
> update failed due to authentication error 
> (org.apache.kafka.clients.admin.internals.AdminMetadataManager)
> org.apache.kafka.common.errors.SaslAuthenticationException: 
> {"status":"invalid_token"}
> Error while executing topic command : {"status":"invalid_token"}
> [2022-03-11 16:21:20,468] ERROR 
> org.apache.kafka.common.errors.SaslAuthenticationException: 
> {"status":"invalid_token"}
>  (kafka.admin.TopicCommand$)
> {noformat}
>  - broker log:
> {noformat}
> [2022-03-11 16:21:20,150] WARN Could not validate the access token: JWT 
> (claims->{"client_id":"...","iss":"...","iat":1647012079,"exp":1647015679,"aud":[...],"env":"...","org":"..."})
>  rejected due to invalid claims or other invalid content. Additional details: 
> [[14] No Subject (sub) claim is present.] 
> (org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler)
> org.apache.kafka.common.security.oauthbearer.secured.ValidateException: Could 
> not validate the access token: JWT 
> (claims->{"client_id":"...","iss":

[jira] [Resolved] (KAFKA-13983) Support special character in Resource name in ACLs operation by sanitizing

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-13983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-13983.
---
Fix Version/s: 3.3.0
 Reviewer: Manikumar
   Resolution: Fixed

> Support special character in Resource name in ACLs operation by sanitizing 
> ---
>
> Key: KAFKA-13983
> URL: https://issues.apache.org/jira/browse/KAFKA-13983
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Reporter: Aman Singh
>Assignee: Aman Singh
>Priority: Minor
> Fix For: 3.3.0
>
>
> Currently, resource names in ACLS can contain any special characters, but 
> resource names with some special characters are not a valid zookeeper path 
> entry.
> For example resource name {color:#de350b}{{test/true}} {color}is not a valid 
> zookeeper path entry.
> Zookeeper will create a child node, name as {color:#de350b}{{true}}{color} 
> inside the {color:#de350b}{{test}}{color} node.
> This will create two problems:-
>  # If there is *one*  ACL with a resource name {color:#de350b}{{test}}{color} 
> it can't be deleted because if there is only one, Kafka tries to delete the 
> node as well by thinking it will be empty which is not true it has the child 
> node {{{color:#de350b}true{color}.}}
>  # When broker restarts {color:#de350b}{{ACL cache}}{color}(which is used for 
> ACL operations like describe, authorization etc) update from zookeeper and 
> Kafka only looks for  ACLs that are direct child nodes of resource type in 
> the ACL tree. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New committer: Luke Chen

[Manikumar]

Congrats Luke!

On Thu, Feb 10, 2022 at 1:36 PM Mickael Maison 
wrote:

> Congratulations Luke!
>
> On Thu, Feb 10, 2022 at 8:54 AM Tom Bentley  wrote:
> >
> > Congratulations Luke!
> >
> > On Thu, 10 Feb 2022 at 06:41, Josep Prat 
> > wrote:
> >
> > > Congrats Luke!
> > >
> > > ———
> > > Josep Prat
> > >
> > > Aiven Deutschland GmbH
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > m: +491715557497
> > >
> > > w: aiven.io
> > >
> > > e: josep.p...@aiven.io
> > >
> > > On Thu, Feb 10, 2022, 07:07 Randall Hauch  wrote:
> > >
> > > > Congratulations, Luke!
> > > >
> > > > On Wed, Feb 9, 2022 at 11:02 PM Matthias J. Sax 
> > > wrote:
> > > >
> > > > > Congratulations! Glad to have you onboard, Luke!
> > > > >
> > > > > -Matthias
> > > > >
> > > > > On 2/9/22 16:37, Bill Bejeck wrote:
> > > > > > Congrats Luke! Well deserved.
> > > > > >
> > > > > > -Bill
> > > > > >
> > > > > > On Wed, Feb 9, 2022 at 7:25 PM Israel Ekpo  >
> > > > wrote:
> > > > > >
> > > > > >> Congratulations Luke!
> > > > > >>
> > > > > >> Thank you for your service
> > > > > >>
> > > > > >> On Wed, Feb 9, 2022 at 6:22 PM Guozhang Wang <
> wangg...@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >>> The PMC for Apache Kafka has invited Luke Chen (showuon) as a
> > > > committer
> > > > > >> and
> > > > > >>> we are pleased to announce that he has accepted!
> > > > > >>>
> > > > > >>> Luke has been actively contributing to Kafka since early 2020.
> He
> > > has
> > > > > >>> made more than 120 commits on various components of Kafka, with
> > > > notable
> > > > > >>> contributions to the rebalance protocol in Consumer and Streams
> > > > > (KIP-766,
> > > > > >>> KIP-726, KIP-591, KAFKA-12675 and KAFKA12464, to just name a
> few),
> > > as
> > > > > >> well
> > > > > >>> as making an impact on improving test stability of the project.
> > > Aside
> > > > > >> from
> > > > > >>> all his code contributions, Luke has been a great participant
> in
> > > > > >>> discussions across the board, a very active and helpful
> reviewer of
> > > > > other
> > > > > >>> contributors' works, all of which are super valuable and highly
> > > > > >> appreciated
> > > > > >>> by the community.
> > > > > >>>
> > > > > >>>
> > > > > >>> Thanks for all of your contributions Luke. Congratulations!
> > > > > >>>
> > > > > >>> -- Guozhang, on behalf of the Apache Kafka PMC
> > > > > >>>
> > > > > >> --
> > > > > >> Israel Ekpo
> > > > > >> Lead Instructor, IzzyAcademy.com
> > > > > >> https://www.youtube.com/c/izzyacademy
> > > > > >> https://izzyacademy.com/
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
>

Re: [VOTE] KIP-801 new authorizer for kip-500 kraft mode

[Manikumar]

+1 (binding). Thanks for the KIP.

On Tue, Feb 1, 2022 at 10:43 PM Jason Gustafson 
wrote:

> +1 Thanks!
>
> On Mon, Jan 31, 2022 at 6:20 PM Colin McCabe  wrote:
>
> > Hi all,
> >
> > It looks like people using gmail are seeing the previous vote thread as
> > merged with the discuss thread, so let me create a new thread in order to
> > avoid confusion. Usually using a very different thread title works well
> > enough to avoid the merging.
> >
> > Original vote thread:
> > https://lists.apache.org/thread/jwjhpdll4jp3y6lo9kox3p5thwo8qpk3
> >
> > best,
> > Colin
> >
>

Re: [DISCUSS] KIP-801: Implement an Authorizer that stores metadata in __cluster_metadata

[Manikumar]

Thanks for the KIP. LGTM once we get consensus on bootstrapping logic.

1. When do we say, ACL is created (or deleted)? Is it after we persist it
durably by a majority of peers?.
2. Can we add a metric for total acl count (This was missing in ZK
Authoriser).

On Thu, Jan 13, 2022 at 2:26 AM David Arthur
 wrote:

> Sounds good on the ordering, and yea I agree we can look at atomic ACL
> modifications in the future. Thanks!
>
> On Wed, Jan 12, 2022 at 3:53 PM Colin McCabe  wrote:
>
> > Hi David,
> >
> > On Wed, Dec 15, 2021, at 07:28, David Arthur wrote:
> > > 5) Ok, gotcha. So will the StandardAuthorizer be replaying records
> > > directly, or will it get an *Image like other metadata consumers on the
> > > broker?
> > >
> >
> > It reads the information out of the MetadataDelta, being careful to
> > preserve the ordering of the changes.
> >
> > The current implementation uses a LinkedHashMap to preserve that
> ordering.
> > You can take a look at the PR here:
> > https://github.com/apache/kafka/pull/11649/files
> >
> > > 6) I was thinking since the CreateAcl and DeleteAcl requests can modify
> > > multiple ACL in one request, that we should reflect that by committing
> > the
> > > resulting records as an atomic batch. I think from an operators
> > > perspective, they would expect the ACLs sent in their request to be
> > > enacted together atomically.
> > >
> >
> > That's never been guaranteed, though. Creating multiple ACLs in ZK
> > requires changing multiple znodes, which is not atomic. Given that users
> > haven't asked for this and it would add substantial complexity, can be
> > discuss it later once we have feature parity with the ZK version?
> >
> > best,
> > Colin
> >
> >
> > >
> > >
> > > On Tue, Dec 14, 2021 at 4:20 PM Colin McCabe 
> wrote:
> > >
> > >> On Tue, Dec 14, 2021, at 08:27, José Armando García Sancio wrote:
> > >> > Thanks for the additional information Colin.
> > >> >
> > >> ...
> > >> >
> > >> > It sounds to me like KIP-801 is assuming that this "bootstrapping
> KIP"
> > >> > will at least generate a snapshot with this information in all of
> the
> > >> > controllers. I would like to understand this a bit better. Do you
> > >> > think that we need to write this "bootstrapping KIP" as soon as
> > >> > possible?
> > >> >
> > >>
> > >> Hi José,
> > >>
> > >> I don't know about "as soon as possible." The authorizer is useful
> even
> > >> without the bootstrapping KIP, as I mentioned (just using
> super.users).
> > But
> > >> I do think we'll need the bootstrapping KIP before KRaft goes GA.
> > >>
> > >> best,
> > >> Colin
> > >>
> > >
> > >
> > > --
> > > -David
> >
>
>
> --
> -David
>

Re: [kafka-clients] [VOTE] 2.7.2 RC0

[Manikumar]

Hi,

+1 (binding)

- verified the signatures
- verified the quickstart with binary

Thanks for running the release!

Thanks,
Manikumar

On Tue, Nov 2, 2021 at 11:16 PM Mickael Maison  wrote:

> Bumping the thread.
>
> Contributors, committers and PMC, please take some time to test this
> release candidate and vote.
>
> Thanks,
> Mickael
>
> On Tue, Oct 26, 2021 at 7:38 PM Israel Ekpo  wrote:
> >
> > Thanks Bill. That is greatly appreciated :)
> >
> > We need more PMC members with binding votes to participate.
> >
> > You can do it!
> >
> > On Tue, Oct 26, 2021 at 1:25 PM Bill Bejeck  wrote:
> >>
> >> Hi Mickael,
> >>
> >> Thanks for running the release.
> >>
> >> Steps taken
> >>
> >> Validated checksums
> >> Validated signatures
> >> Built from source
> >> Ran all the unit tests
> >> Spot checked various JavaDocs
> >>
> >>
> >> +1(binding)
> >>
> >> On Tue, Oct 26, 2021 at 4:43 AM Luke Chen  wrote:
> >>>
> >>> Hi Mickael,
> >>>
> >>> Thanks for the release. I did:
> >>> 1. Verified checksums and signatures
> >>> 2. Run quick start steps
> >>> 3. Verified the CVE-2021-38153 is indeed fixed in kafka-2.7.2-src.tgz
> >>> <https://home.apache.org/~mimaison/kafka-2.7.2-rc0/kafka-2.7.2-src.tgz
> >.
> >>>
> >>> +1 (non-binding)
> >>>
> >>> Thank you.
> >>> Luke
> >>>
> >>> On Tue, Oct 26, 2021 at 3:41 PM Tom Bentley 
> wrote:
> >>>
> >>> > Hi Mickael,
> >>> >
> >>> > As with 2.6.3 RC0, I have:
> >>> >
> >>> > * Verified checksums and signatures
> >>> > * Built jars and docs from the source jar
> >>> > * Run the unit and integration tests
> >>> >
> >>> > +1 non-binding
> >>> >
> >>> > Kind regards,
> >>> >
> >>> > Tom
> >>> >
> >>> > On Sun, Oct 24, 2021 at 3:05 PM Israel Ekpo 
> wrote:
> >>> >
> >>> > > Mickael,
> >>> > >
> >>> > > Do we need to do another RC? Were there issues with this release?
> >>> > >
> >>> > > What happens next?
> >>> > >
> >>> > >
> >>> > > On Sat, Oct 16, 2021 at 8:11 PM Israel Ekpo 
> >>> > wrote:
> >>> > >
> >>> > > >
> >>> > > > I have performed the following checks
> >>> > > >
> >>> > > > Validation of Release Artifacts Cryptographic Hashes (ASC MD5
> SHA1
> >>> > > SHA512)
> >>> > > > PGP Signatures used to sign the release artifacts
> >>> > > > Javadocs check
> >>> > > > Site docs check was not necessary
> >>> > > > Jenkins build was successful.
> >>> > > >
> >>> > > > I used the steps here for the first two checks
> >>> > > > https://github.com/izzyacademy/apache-kafka-release-party
> >>> > > >
> >>> > > > I vote +1 on this RC
> >>> > > >
> >>> > > >
> >>> > > > On Fri, Oct 15, 2021 at 12:11 PM Israel Ekpo <
> israele...@gmail.com>
> >>> > > wrote:
> >>> > > >
> >>> > > >> Hi Mickael,
> >>> > > >>
> >>> > > >> I am pretty surprised that there are no votes so far on the RCs
> and
> >>> > the
> >>> > > >> deadline has already passed.
> >>> > > >>
> >>> > > >> I am running my checks right now using the process outlined here
> >>> > > >>
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> >
> https://github.com/izzyacademy/apache-kafka-release-party#how-to-validate-apache-kafka-release-candidates
> >>> > > >>
> >>> > > >> I will post my results and vote as soon as they are completed.
> >>> > > >>
> >>> > > >> On Fri, Oct 15, 2021 at 9:52 AM Mickael Maison <
> mimai...@apache.org>
> >>> > > >> wrote:
> >>> > > >>
> >>> > > 

Re: [kafka-clients] [VOTE] 2.6.3 RC0

[Manikumar]

Hi,

+1 (binding)

- verified the signatures
- verified the quickstart with binary

Thanks for running the release!

Thanks,
Manikumar

On Tue, Nov 2, 2021 at 11:15 PM Mickael Maison 
wrote:

> Bumping the thread.
>
> Contributors, committers and PMC, please take some time to test this
> release candidate and vote.
>
> Thanks,
> Mickael
>
> On Tue, Oct 26, 2021 at 4:50 PM Bill Bejeck  wrote:
> >
> > Thanks for running the release Mickael.
> >
> > I did the following:
> >
> >1. Validated signatures
> >2. Validated checksums
> >3. Built from source
> >4. Ran all the unit tests
> >5. Spot checked the Javadocs
> >
> >
> > +1(binding)
> > -Bill
> >
> >
> >
> > On Mon, Oct 25, 2021 at 8:24 PM Israel Ekpo 
> wrote:
> >
> > > Hello Friends
> > >
> > > We are approaching the limit of the grace period for your vote events
> to
> > > make in into the result stream. Just kidding :) KIP-633 added 24 more
> weeks
> > > to the grace period :)
> > >
> > > All kidding aside, lets take a few moments and validate the RC and
> vote yes
> > > (+1) or no (-1) so that we can close out the process soon.
> > >
> > > That being said let’s get started with the release party
> > >
> > > I have simplified the validation process here
> > >
> > > https://github.com/izzyacademy/apache-kafka-release-party
> > >
> > > All you need is Docker in your local environment and the validation can
> > > be done in a few moments
> > >
> > > Let’s try to complete the voting process so that we can push this
> release
> > > out and resolve the outstanding vulnerabilities and defects already
> > > resolved.
> > >
> > > Thanks
> > >
> > > On Mon, Oct 25, 2021 at 12:34 PM Tom Bentley 
> wrote:
> > >
> > > > Hi Mickael,
> > > >
> > > > I have:
> > > >
> > > > * Verified checksums and signatures
> > > > * Built jars and docs from the source jar
> > > > * Run the unit and integration tests
> > > >
> > > > +1 non-binding
> > > >
> > > > Kind regards,
> > > >
> > > > Tom
> > > >
> > > > On Mon, Oct 25, 2021 at 10:07 AM Mickael Maison  >
> > > > wrote:
> > > >
> > > > > Hi Israel,
> > > > >
> > > > > Thanks for checking this RC and voting!
> > > > > The vote is not abandoned, we are just waiting for people to vote.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Oct 24, 2021 at 3:59 PM Israel Ekpo 
> > > > wrote:
> > > > > >
> > > > > > Was this vote abandoned? If so why?
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 16, 2021 at 8:12 PM Israel Ekpo <
> israele...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > I have performed the following checks for this release
> candidate.
> > > > > > >
> > > > > > > Validation of Release Artifacts Cryptographic Hashes (ASC MD5
> SHA1
> > > > > SHA512)
> > > > > > > PGP Signatures used to sign the release artifacts
> > > > > > > Javadocs check
> > > > > > > Site docs check was not necessary
> > > > > > > Jenkins build was successful.
> > > > > > >
> > > > > > > I used the steps here for the first two checks
> > > > > > > https://github.com/izzyacademy/apache-kafka-release-party
> > > > > > >
> > > > > > > I vote +1 on this RC
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Oct 15, 2021 at 12:11 PM Israel Ekpo <
> israele...@gmail.com
> > > >
> > > > > wrote:
> > > > > > >
> > > > > > >> Hi Mickael,
> > > > > > >>
> > > > > > >> I am pretty surprised that there are no votes so far on the
> RCs
> > > and
> > > > > the
> > > > > > >> deadline has already passed.
> > > > > >

Re: [VOTE] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC

[Manikumar]

Hi Kirk,

Thanks for the KIP!

+1 (binding)


Thanks,
Manikumar

On Mon, Sep 27, 2021 at 10:50 PM Kirk True  wrote:

> Hi all!
>
> I'd like to start a vote for KIP-768 that allows Kafka to connect to an
> OAuth/OIDC identity provider for authentication and token retrieval:
>
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186877575
>
> Thanks!
> Kirk

Re: [VOTE] 2.8.1 RC1

[Manikumar]

Hi,

+1 (binding)

- verified the signatures
- ran the tests on the source archive
- verified the quickstart with binary
- verified the artifacts, javadoc

Thanks for running the release!

Thanks,
Manikumar

On Tue, Sep 14, 2021 at 10:36 PM Chris Egerton 
wrote:

> Hi David,
>
> I took a look at the Javadocs and noticed a small issue. Using the search
> bar at the top of the landing page (
> https://home.apache.org/~dajac/kafka-2.8.1-rc1/javadoc/), I entered
> "KafkaProducer" and clicked on the search item that came up. This brought
> me to
>
> https://home.apache.org/~dajac/kafka-2.8.1-rc1/javadoc/undefined/org/apache/kafka/clients/producer/KafkaProducer.html
> ,
> which displayed a 404 "Not Found" error.
>
> This doesn't appear to be a regression as the same behavior occurs for me
> when browsing the 2.8.0 Javadocs (
> https://kafka.apache.org/28/javadoc/index.html?overview-summary.html), but
> I wanted to bring it up just in case. Normally I don't use the search bar
> but with the removal of sidebar frames from Javadocs I've had to start
> relying on it a little bit more.
>
> Cheers,
>
> Chris
>
> On Tue, Sep 14, 2021 at 12:56 PM Randall Hauch  wrote:
>
> > Thanks for generating a new RC1 with the corrected site docs, David.
> >
> > I was able to successfully complete the following:
> >
> > - Installed 2.8.1 RC0 and performed quickstart for broker and Connect
> > - Verified signatures and checksums
> > - Verified the tag
> > - Manually compared the release notes to JIRA
> > - Build release archive from the tag, ran Connect tests, installed
> locally,
> > and ran a portion of quickstart
> > - Manually spotchecked the Javadocs
> > - Verified the site docs at
> https://kafka.apache.org/28/documentation.html
> > has corrected version references, except for the tar and cd commands in
> > step 1 of the https://kafka.apache.org/28/documentation.html#quickstart.
> >
> > I think that last issue is minor and not worth another RC, since the
> other
> > version references in https://kafka.apache.org/28/documentation.html do
> > reference 2.8.1 and we can easily fix it on the website, optionally as
> part
> > of the other post-vote changes to the site.
> >
> > So I'm +1 (binding)
> >
> > Best regards,
> >
> > Randall
> >
> > On Tue, Sep 14, 2021 at 8:39 AM David Jacot  >
> > wrote:
> >
> > > Hello Kafka users, developers and client-developers,
> > >
> > > This is the second candidate for release of Apache Kafka 2.8.1.
> > >
> > > Apache Kafka 2.8.1 is a bugfix release and fixes 49 issues since the
> > 2.8.0
> > > release. Please see the release notes for more information.
> > >
> > > Release notes for the 2.8.1 release:
> > > https://home.apache.org/~dajac/kafka-2.8.1-rc1/RELEASE_NOTES.html
> > >
> > > *** Please download, test and vote by Friday, September 17, 9am PT
> > >
> > > Kafka's KEYS file containing PGP keys we use to sign the release:
> > > https://kafka.apache.org/KEYS
> > >
> > > * Release artifacts to be voted upon (source and binary):
> > > https://home.apache.org/~dajac/kafka-2.8.1-rc1/
> > >
> > > * Maven artifacts to be voted upon:
> > > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > >
> > > * Javadoc:
> > > https://home.apache.org/~dajac/kafka-2.8.1-rc1/javadoc/
> > >
> > > * Tag to be voted upon (off 2.8 branch) is the 2.8.1 tag:
> > > https://github.com/apache/kafka/releases/tag/2.8.1-rc1
> > >
> > > * Documentation:
> > > https://kafka.apache.org/28/documentation.html
> > >
> > > * Protocol:
> > > https://kafka.apache.org/28/protocol.html
> > >
> > > * Successful Jenkins builds for the 2.8 branch:
> > > Unit/integration tests:
> > > https://ci-builds.apache.org/job/Kafka/job/kafka/job/2.8/80/
> > > System tests:
> > > https://jenkins.confluent.io/job/system-test-kafka/job/2.8/214/
> > >
> > > /**
> > >
> > > Thanks,
> > > David
> > >
> >
>

Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC

[Manikumar]

Thanks for the reply,

Can we also update the KIP about the testing approach?

Thanks,

On Wed, Aug 25, 2021 at 12:01 AM Kirk True  wrote:

> Hi Manikumar!
>
> On Mon, Aug 23, 2021, at 12:59 PM, Manikumar wrote:
>
> Hi Kirk,
>
> Thanks for the KIP!
>
> 1. Do we want to support validating issuers using the issuer uri?
>
>
> Are you referring to validating the JWT was issued by a known, configured
> issuer, or something more different/more dynamic?
>
> The current design allows for optionally requiring that the iss claim
> from the JWT match a statically configured issuer from the configuration.
> See expectedIssuer under the broker configuration.
>
> 2. Can the access token be reused for multiple connections from the same
> client?
>
>
> That's an excellent question - I will double-check that it is reused.
> Hopefully the existing client authentication mechanism supports that level
> of reuse.
>
> 3. Do we support configuring separate ssl configs for connecting
> authorization server/jwks endpoint?
>
>
> Yes, that documentation is forthcoming soon.
>
> It will be a set of configuration options similar to the existing SSL
> socket configuration, but specific to the HTTPS endpoint for the OAuth/OIDC
> provider connections.
>
> 4. Do we want support any readable username as principal if it is present
> in the token claims
>
>
> Yes. See the subClaimName and principalClaimName configuration options.
> Those will allow specifying a claim name other than sub for the principal.
>
> Now that I'm writing this out I realize that the configuration names are
> different on the client and broker for some reason 樂  I'll change that.
>
> 5. I agree with Ron, We should move the public classes to
> "o.a.k.c.s.oauthbearer.secured" package.
>
>
> Sounds good. I made the change in the KIP.
>
> Thanks,
> Manikumar
>
>
> Thanks for your feedback!
>
>
> On Thu, Aug 19, 2021 at 11:46 PM Kirk True  wrote:
>
> > Hi Ron,
> >
> > On Sat, Aug 14, 2021, at 11:27 AM, Ron Dagostino wrote:
> > > Hi Kirk -- thanks for the KIP!  Having concrete implementations
> > > out-of-the-box will be very helpful.
> > >
> > > > As seen in this diagram, the login callback is executed on the client
> > and
> > > the validate callback is executed on the broker.
> > >
> > > There was no diagram when I looked.  Maybe there is a broken link or
> > > something?
> >
> > I double-checked and it's showing for me on the published version of the
> > wiki, even after I've logged out.
> >
> > Would you mind checking again when you get the chance?
> >
> > > > The name of the implementation class will be
> > >
> >
> org.apache.kafka.common.security.oauthbearer.internals.secured.OAuthBearerLoginCallbackHandler
> > >
> > > I think the internals package was meant for non-public stuff  Most of
> it
> > > seems that way, although the "unsecured" implementation is in there --
> > but
> > > that's maybe a grey area since it isn't meant to be used in production
> > > scenarios and is mostly leveraged in unit tests.  Perhaps move the
> > proposed
> > > class into a "o.a.k.c.s.oauthbearer.secured" package?  Then any
> > > implementation details beyond the public stuff can live under the
> > > "...internals.secured" package that you mentioned?  The same comment
> > > applies to the validator callback handler class.
> >
> > In a draft I had the secured package directly under the oauthbearer
> > package as you describe but I received some out-of-band feedback to aim
> for
> > parity with the unsecured package layout.
> >
> > I don't have a preference for either. I do agree that it seems weird for
> a
> > package named internals to be used in configuration since its name
> implies
> > that things could change.
> >
> > > I'm confused by loginRetryMaxWaitMs and loginRetryWaitMs.  The former
> has
> > > "Max" in the name, but only the description of the latter mentions it
> > being
> > > a max amount of time?  Are the descriptions incorrect or perhaps
> > reversed?
> >
> > Yes. Thanks for catching that. I've added more description in a separate
> > paragraph above the enumerated configurations.
> >
> > > >  Ensure the encoding algorithm isn't none and matches what the
> expected
> > > algorithm expecting
> > >
> > > "expected algorithm expecting" some kind of grammar issue?
> >
> > Haha! Yes - th

Re: [DISCUSS] KIP-768: Extend SASL/OAUTHBEARER with Support for OIDC

[Manikumar]

Hi Kirk,

Thanks for the KIP!

1. Do we want to support validating issuers using the issuer uri?
2. Can the access token be reused for multiple connections from the same
client?
3. Do we support configuring separate ssl configs for connecting
authorization server/jwks endpoint?
4. Do we want support any readable username as principal if it is present
in the token claims
5. I agree with Ron, We should move the public classes to
"o.a.k.c.s.oauthbearer.secured" package.

Thanks,
Manikumar

On Thu, Aug 19, 2021 at 11:46 PM Kirk True  wrote:

> Hi Ron,
>
> On Sat, Aug 14, 2021, at 11:27 AM, Ron Dagostino wrote:
> > Hi Kirk -- thanks for the KIP!  Having concrete implementations
> > out-of-the-box will be very helpful.
> >
> > > As seen in this diagram, the login callback is executed on the client
> and
> > the validate callback is executed on the broker.
> >
> > There was no diagram when I looked.  Maybe there is a broken link or
> > something?
>
> I double-checked and it's showing for me on the published version of the
> wiki, even after I've logged out.
>
> Would you mind checking again when you get the chance?
>
> > > The name of the implementation class will be
> >
> org.apache.kafka.common.security.oauthbearer.internals.secured.OAuthBearerLoginCallbackHandler
> >
> > I think the internals package was meant for non-public stuff  Most of it
> > seems that way, although the "unsecured" implementation is in there --
> but
> > that's maybe a grey area since it isn't meant to be used in production
> > scenarios and is mostly leveraged in unit tests.  Perhaps move the
> proposed
> > class into a "o.a.k.c.s.oauthbearer.secured" package?  Then any
> > implementation details beyond the public stuff can live under the
> > "...internals.secured" package that you mentioned?  The same comment
> > applies to the validator callback handler class.
>
> In a draft I had the secured package directly under the oauthbearer
> package as you describe but I received some out-of-band feedback to aim for
> parity with the unsecured package layout.
>
> I don't have a preference for either. I do agree that it seems weird for a
> package named internals to be used in configuration since its name implies
> that things could change.
>
> > I'm confused by loginRetryMaxWaitMs and loginRetryWaitMs.  The former has
> > "Max" in the name, but only the description of the latter mentions it
> being
> > a max amount of time?  Are the descriptions incorrect or perhaps
> reversed?
>
> Yes. Thanks for catching that. I've added more description in a separate
> paragraph above the enumerated configurations.
>
> > >  Ensure the encoding algorithm isn't none and matches what the expected
> > algorithm expecting
> >
> > "expected algorithm expecting" some kind of grammar issue?
>
> Haha! Yes - thanks for catching that too!
>
> It now reads:
>
> > Ensure the encoding algorithm (`alg` from the header) isn't `none` and
> matches the expected algorithm for the JWK ID
>
> > Thanks again -- very exciting!
>
> Thanks for the feedback!!!
>
> Kirk
>
> >
> > Ron
> >
> >
> >
> >
> >
> > On Fri, Aug 13, 2021 at 3:53 PM Kirk True  wrote:
> >
> > > Hi all!
> > >
> > > I have created a new KIP for a new OAuth/OIDC related authentication
> > > feature.
> > >
> > > This task is to provide a concrete implementation of the interfaces
> > > defined in KIP-255 to allow Kafka to connect to an OAuth / OIDC
> identity
> > > provider for authentication and token retrieval. While KIP-255
> provides an
> > > unsecured JWT example for development purposes, this will fill in the
> gap
> > > and provide a production-grade implementation.
> > >
> > > Here's the KIP:
> > >
> > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186877575
> > >
> > > Thanks!
> > > Kirk
> >
>

[jira] [Resolved] (KAFKA-12985) CVE-2021-28169 - Upgrade jetty to 9.4.41

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-12985.
---
Fix Version/s: 2.8.1
   2.7.2
   3.0.0
   Resolution: Fixed

> CVE-2021-28169 - Upgrade jetty to 9.4.41
> 
>
> Key: KAFKA-12985
> URL: https://issues.apache.org/jira/browse/KAFKA-12985
> Project: Kafka
>  Issue Type: Task
>  Components: security
>Reporter: Dongjin Lee
>Assignee: Dongjin Lee
>Priority: Minor
> Fix For: 3.0.0, 2.7.2, 2.8.1
>
>
> CVE-2021-28169 vulnerability affects Jetty versions up to 9.4.40. For more 
> information see https://nvd.nist.gov/vuln/detail/CVE-2021-28169
> Upgrading to Jetty version 9.4.41 should address this issue 
> (https://github.com/eclipse/jetty.project/security/advisories/GHSA-gwcr-j4wh-j3cq).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-13041) Support debugging system tests with ducker-ak

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-13041.
---
Fix Version/s: 3.0.0
   Resolution: Fixed

> Support debugging system tests with ducker-ak
> -
>
> Key: KAFKA-13041
> URL: https://issues.apache.org/jira/browse/KAFKA-13041
> Project: Kafka
>  Issue Type: Improvement
>  Components: system tests
>Reporter: Stanislav Vodetskyi
>Priority: Major
> Fix For: 3.0.0
>
>
> Currently when you're using ducker-ak to run system tests locally, your only 
> debug option is to add print/log messages.
> It should be possible to connect to a ducker-ak test with a remote debugger.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [CWIKI] Contributing Code Changes update

[Manikumar]

Hi,

I've given you the wiki permissions. Thanks for your interest in the Kafka
Project.

Thanks,
Manikumar


On Fri, Jun 11, 2021 at 6:11 PM Martin Tzvetanov Grigorov <
mgrigo...@apache.org> wrote:

> Hello Kafka devs,
>
> I am reading
> https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes
> and I've found few things which could be improved:
>
> For example:
>  - "The Jenkins will not automatic builder for pull request. " needs to be
> re-worded
> - " In the near future, we will also be able to run the system tests in
> Travis (progress can be tracked via  KAFKA-4463 - Setup travis-ci
> integration for ducktape tests PATCH AVAILABLE )." - I guess this idea have
> been dropped because TravisCI is not used by the project
> - also it would be nice to mention that PRs are tested on both AMD64 and
> ARM64 CPU architectures at Jenkins
>
> I could make those changes myself if you give me permissions! My id is
> 'mgrigorov'.
>
> Regards,
> Martin
>

[jira] [Resolved] (KAFKA-12866) Kafka requires ZK root access even when using a chroot

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-12866.
---
Resolution: Fixed

> Kafka requires ZK root access even when using a chroot
> --
>
> Key: KAFKA-12866
> URL: https://issues.apache.org/jira/browse/KAFKA-12866
> Project: Kafka
>  Issue Type: Bug
>  Components: core, zkclient
>Affects Versions: 2.6.1, 2.8.0, 2.7.1, 2.6.2
>Reporter: Igor Soarez
>Assignee: Igor Soarez
>Priority: Major
> Fix For: 3.0.0
>
>
> When a Zookeeper chroot is configured, users do not expect Kafka to need 
> Zookeeper access outside of that chroot.
> h1. Why is this important?
> A zookeeper cluster may be shared with other Kafka clusters or even other 
> applications. It is an expected security practice to restrict each 
> cluster/application's access to it's own Zookeeper chroot.
> h1. Steps to reproduce
> h2. Zookeeper setup
> Using the zkCli, create a chroot for Kafka, make it available to Kafka but 
> lock the root znode.
>  
> {code:java}
> [zk: localhost:2181(CONNECTED) 1] create /somechroot
> Created /some
> [zk: localhost:2181(CONNECTED) 2] setAcl /somechroot world:anyone:cdrwa
> [zk: localhost:2181(CONNECTED) 3] addauth digest test:12345
> [zk: localhost:2181(CONNECTED) 4] setAcl / 
> digest:test:Mx1uO9GLtm1qaVAQ20Vh9ODgACg=:cdrwa{code}
>  
> h2. Kafka setup
> Configure the chroot in broker.properties:
>  
> {code:java}
> zookeeper.connect=localhost:2181/somechroot{code}
>  
>  
> h2. Expected behavior
> The expected behavior here is that Kafka will use the chroot without issues.
> h2. Actual result
> Kafka fails to start with a fatal exception:
> {code:java}
> org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = 
> NoAuth for /chroot
> at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:120)
> at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
> at kafka.zookeeper.AsyncResponse.maybeThrow(ZooKeeperClient.scala:583)
> at kafka.zk.KafkaZkClient.createRecursive(KafkaZkClient.scala:1729)
> at 
> kafka.zk.KafkaZkClient.makeSurePersistentPathExists(KafkaZkClient.scala:1627)
> at kafka.zk.KafkaZkClient$.apply(KafkaZkClient.scala:1957)
> at 
> kafka.zk.ZkClientAclTest.testChrootExistsAndRootIsLocked(ZkClientAclTest.scala:60)
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-12865) Documentation error for Admin Client API in describe ACLs

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-12865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-12865.
---
Fix Version/s: 3.0.0
   Resolution: Fixed

> Documentation error for Admin Client API in describe ACLs
> -
>
> Key: KAFKA-12865
> URL: https://issues.apache.org/jira/browse/KAFKA-12865
> Project: Kafka
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.8.0
>Reporter: Rohit Sachan
>Priority: Major
> Fix For: 3.0.0
>
>
> There is a documentation bug in *Admin.java's* `describeAcls` and its 
> overloaded variation, function's return type shows `*DeleteAclsResult*` 
> instead of `*DescribeAclResult*`. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-12820) Upgrade maven-artifact dependency to resolve CVE-2021-26291

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-12820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-12820.
---
Fix Version/s: 2.8.1
   2.7.2
   2.6.3
   3.0.0
   Resolution: Fixed

> Upgrade maven-artifact dependency to resolve CVE-2021-26291
> ---
>
> Key: KAFKA-12820
> URL: https://issues.apache.org/jira/browse/KAFKA-12820
> Project: Kafka
>  Issue Type: Task
>  Components: build
>Affects Versions: 2.6.1, 2.8.0, 2.7.1
>Reporter: Boojapho
>Assignee: Dongjin Lee
>Priority: Major
> Fix For: 3.0.0, 2.6.3, 2.7.2, 2.8.1
>
>
> Current Gradle builds of Kafka contain a dependency of `maven-artifact` 
> version 3.6.3, which contains CVE-2021-26291 
> ([https://nvd.nist.gov/vuln/detail/CVE-2021-26291).]  This vulnerability has 
> been fixed in Maven 3.8.1 
> ([https://maven.apache.org/docs/3.8.1/release-notes.html]).  Apache Kafka 
> should update `dependencies.gradle` to use the latest `maven-artifact` 
> library to eliminate this vulnerability.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] KIP-734: Improve AdminClient.listOffsets to return timestamp and offset for the record with the largest timestamp

[Manikumar]

+1 (binding)

Thanks for the KIP.

Manikumar

On Mon, May 17, 2021 at 5:20 PM Rajini Sivaram 
wrote:

> +1 (binding)
>
> Thanks for the KIP, Tom!
>
> Regards,
>
> Rajini
>
>
> On Mon, May 17, 2021 at 12:42 PM David Jacot 
> wrote:
>
> > +1 (binding)
> >
> > Thanks for the KIP, Tom.
> >
> > Best,
> > David
> >
> > On Fri, Apr 23, 2021 at 12:42 PM Thomas Scott 
> > wrote:
> >
> > > Hey all,
> > >
> > >   I'm starting the voting on KIP-734.
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-734%3A+Improve+AdminClient.listOffsets+to+return+timestamp+and+offset+for+the+record+with+the+largest+timestamp
> > >
> > > Thanks
> > >
> > >   Tom
> > >
> >
>

[jira] [Resolved] (KAFKA-12752) CVE-2021-28168 upgrade jersey to 2.34 or 3.02

[Manikumar (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-12752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar resolved KAFKA-12752.
---
Fix Version/s: 2.8.1
   2.7.2
   3.0.0
 Reviewer: Manikumar
   Resolution: Fixed

> CVE-2021-28168 upgrade jersey to 2.34 or 3.02
> -
>
> Key: KAFKA-12752
> URL: https://issues.apache.org/jira/browse/KAFKA-12752
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: John Stacy
>Assignee: Dongjin Lee
>Priority: Major
>  Labels: CVE, security
> Fix For: 3.0.0, 2.7.2, 2.8.1
>
>
> [https://nvd.nist.gov/vuln/detail/CVE-2021-28168]
> CVE-2021-28168 affects jersey versions <=2.33, <=3.0.1. Upgrading to 2.34 or 
> 3.02 should resolve the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

[Manikumar]

+1 (binding)



On Mon, Mar 22, 2021 at 9:42 AM Gwen Shapira 
wrote:

> Woot!
> +1
>
> On Sat, Mar 20, 2021, 10:41 AM Ryanne Dolan  wrote:
>
> > Hey y'all, I'm starting the vote on KIP-720, which proposes to deprecate
> > the original MirrorMaker in the upcoming 3.0 major release.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-720%3A+Deprecate+MirrorMaker+v1
> >
> > Thanks!
> > Ryanne
> >
>

Re: [VOTE] KIP-717: Deprecate batch-size config from console producer

[Manikumar]

Hi Kamal,

It looks like we just forgot this config, when we removed old producer
code.  I think we dont require KIP for this.
we can directly fix with a minor PR .

Thanks.

On Wed, Mar 17, 2021 at 7:02 PM Dongjin Lee  wrote:

> +1. (non-binding)
>
> Thanks,
> Dongjin
>
> On Thu, Mar 11, 2021 at 5:52 PM Manikumar 
> wrote:
>
> > +1 (binding). Thanks for the KIP
> > I think we can remove the config option as the config option is unused.
> >
> > On Wed, Mar 10, 2021 at 3:06 PM Kamal Chandraprakash <
> > kamal.chandraprak...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I'd like to start a vote on KIP-717 to remove batch-size config from
> the
> > > console producer.
> > >
> > > https://cwiki.apache.org/confluence/x/DB1RCg
> > >
> > > Thanks,
> > > Kamal
> > >
> >
> --
> *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>*
>

Re: request permission to create KIP

[Manikumar]

Hi,

I have given you the wiki permissions to create KIP. Thanks for your
interest in the Kafka Project.

Thanks,

On Wed, Mar 17, 2021 at 6:40 AM Andrei Iatsuk  wrote:

> Hello!
>
> I create improvement task
> https://issues.apache.org/jira/browse/KAFKA-12481 <
> https://issues.apache.org/jira/browse/KAFKA-12481> and offered pull
> request https://github.com/apache/kafka/pull/10333 <
> https://github.com/apache/kafka/pull/10333> that solves it. ijuma <
> https://github.com/ijuma> says that according to
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> <
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals>
> I should create KIP.
>
> So can you add me https://cwiki.apache.org/confluence/display/~a.iatsuk <
> https://cwiki.apache.org/confluence/display/~a.iatsuk> permission to
> create KIP?
>
> Best regards,
> Andrei Iatsuk.

Re: [DISCUSS] KIP-720: Deprecate MirrorMaker v1

[Manikumar]

+1. Thanks for the KIP.


On Sun, Mar 14, 2021 at 12:24 PM Ryanne Dolan  wrote:

> Hey y'all, I'd like to start the discussion on KIP-720, which proposes to
> deprecate the original MirrorMaker in the upcoming 3.0 major release.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-720%3A+Deprecate+MirrorMaker+v1
>
> Thanks!
> Ryanne
>

Re: Request to add on Jira Board of Kafa

[Manikumar]

Hi,

Thanks for your interest in the Kafka Project. I have added you to the
contributors list.

Manikumar

On Sun, Mar 14, 2021 at 1:56 AM DV Singh 
wrote:

> Hi there,
>
> I hope you are doing well this weekend!
>
> my jira username is dvsingh9 and email is dsi...@protonmail.com. I would
> like to contribute to kafka project, please add me to jira board so that I
> can assign tickets and start working ...
>
> Regards,
> -DV

Re: [VOTE] KIP-717: Deprecate batch-size config from console producer

[Manikumar]

+1 (binding). Thanks for the KIP
I think we can remove the config option as the config option is unused.

On Wed, Mar 10, 2021 at 3:06 PM Kamal Chandraprakash <
kamal.chandraprak...@gmail.com> wrote:

> Hi,
>
> I'd like to start a vote on KIP-717 to remove batch-size config from the
> console producer.
>
> https://cwiki.apache.org/confluence/x/DB1RCg
>
> Thanks,
> Kamal
>