[jira] [Created] (KAFKA-16467) Add README to docs folder

[PoAn Yang (Jira)]

PoAn Yang created KAFKA-16467:
-

 Summary: Add README to docs folder
 Key: KAFKA-16467
 URL: https://issues.apache.org/jira/browse/KAFKA-16467
 Project: Kafka
  Issue Type: Test
Reporter: PoAn Yang
Assignee: PoAn Yang


We don't have a guide in project root folder or docs folder to show how to run 
local website. It's good to provide a way to run document with kafka-site 
repository.



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

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[Justine Olshan]

Updated!

Justine

On Tue, Apr 2, 2024 at 2:40 PM Jun Rao  wrote:

> Hi, Justine,
>
> Thanks for the reply.
>
> 21. Sounds good. It would be useful to document that.
>
> 22. Should we add the IV in "metadata.version=17 has no dependencies" too?
>
> Jun
>
>
> On Tue, Apr 2, 2024 at 11:31 AM Justine Olshan
> 
> wrote:
>
> > Jun,
> >
> > 21. Next producer ID field doesn't need to be populated for TV 1. We
> don't
> > have the same need to retain this since it is written directly to the
> > transaction log in InitProducerId. It is only needed for KIP-890 part 2 /
> > TV 2.
> >
> > 22. We can do that.
> >
> > Justine
> >
> > On Tue, Apr 2, 2024 at 10:41 AM Jun Rao 
> wrote:
> >
> > > Hi, Justine,
> > >
> > > Thanks for the reply.
> > >
> > > 21. What about the new NextProducerId field? Will that be populated
> with
> > TV
> > > 1?
> > >
> > > 22. In the dependencies output, should we show both IV and level for
> > > metadata.version too?
> > >
> > > Jun
> > >
> > > On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan
> >  > > >
> > > wrote:
> > >
> > > > Hi Jun,
> > > >
> > > > 20. I can update the KIP.
> > > >
> > > > 21. This is used to complete some of the work with KIP-360. (We use
> > > > previous producer ID there, but never persisted it which was in the
> KIP
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820)
> > > > The KIP also mentions including previous epoch but we explained in
> this
> > > KIP
> > > > how we can figure this out.
> > > >
> > > > Justine
> > > >
> > > >
> > > >
> > > > On Mon, Apr 1, 2024 at 3:56 PM Jun Rao 
> > wrote:
> > > >
> > > > > Hi, Justine,
> > > > >
> > > > > Thanks for the updated KIP. A couple of more comments.
> > > > >
> > > > > 20. Could we show the output of version-mapping?
> > > > >
> > > > > 21. "Transaction version 1 will include the flexible fields in the
> > > > > transaction state log, and transaction version 2 will include the
> > > changes
> > > > > to the transactional protocol as described by KIP-890 (epoch bumps
> > and
> > > > > implicit add partitions.)"
> > > > >   So TV 1 enables the writing of new tagged fields like
> > PrevProducerId?
> > > > But
> > > > > those fields are only usable after the epoch bump, right? What
> > > > > functionality does TV 1 achieve?
> > > > >
> > > > > Jun
> > > > >
> > > > >
> > > > > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
> > > >  > > > > >
> > > > > wrote:
> > > > >
> > > > > > I have also updated the KIP to mention the feature tool's
> > --metadata
> > > > flag
> > > > > > will be deprecated.
> > > > > > It will still work for users as they learn the new flag, but a
> > > warning
> > > > > > indicating the alternatives will be shown.
> > > > > >
> > > > > > Justine
> > > > > >
> > > > > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan <
> > > jols...@confluent.io>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Jun,
> > > > > > >
> > > > > > > For both transaction state and group coordinator state, there
> are
> > > > only
> > > > > > > version 0 records.
> > > > > > > KIP-915 introduced flexible versions, but it was never put to
> > use.
> > > MV
> > > > > has
> > > > > > > never gated these. This KIP will do that. I can include this
> > > context
> > > > in
> > > > > > the
> > > > > > > KIP.
> > > > > > >
> > > > > > > I'm happy to modify his 1 and 2 to 0 and 1.
> > > > > > >
> > > > > > > Justine
> > > > > > >
> > > > > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao
> >  > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> Hi, David,
> > > > > > >>
> > > > > > >> Thanks for the reply.
> > > > > > >>
> > > > > > >> Historically, the format of all records were controlled by MV.
> > > Now,
> > > > > > >> records
> > > > > > >> in _offset_commit will be controlled by
> > > `group.coordinator.version`,
> > > > > is
> > > > > > >> that right? It would be useful to document that.
> > > > > > >>
> > > > > > >> Also, we should align on the version numbering. "kafka-feature
> > > > > disable"
> > > > > > >> says "Disable one or more feature flags. This is the same as
> > > > > downgrading
> > > > > > >> the version to zero". So, in the `group.coordinator.version'
> > case,
> > > > we
> > > > > > >> probably should use version 0 for the old consumer protocol.
> > > > > > >>
> > > > > > >> Jun
> > > > > > >>
> > > > > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
> > > > > > >> andrew_schofield_j...@outlook.com> wrote:
> > > > > > >>
> > > > > > >> > Hi David,
> > > > > > >> > I agree that we should use the same mechanism to gate
> KIP-932
> > > once
> > > > > > that
> > > > > > >> > feature reaches production readiness. The precise details of
> > the
> > > > > > values
> > > > > > >> > will
> > > > > > >> > depend upon the current state of all these flags when that
> > > release
> > > > > > >> comes.
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Andrew
> > > > > > >> >
> > > > > > >> > > On 28 Mar 2024, at 07:11, David Jacot
> > > >  > > > > >
> > > > > > >> > 

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[Jun Rao]

Hi, Justine,

Thanks for the reply.

21. Sounds good. It would be useful to document that.

22. Should we add the IV in "metadata.version=17 has no dependencies" too?

Jun


On Tue, Apr 2, 2024 at 11:31 AM Justine Olshan 
wrote:

> Jun,
>
> 21. Next producer ID field doesn't need to be populated for TV 1. We don't
> have the same need to retain this since it is written directly to the
> transaction log in InitProducerId. It is only needed for KIP-890 part 2 /
> TV 2.
>
> 22. We can do that.
>
> Justine
>
> On Tue, Apr 2, 2024 at 10:41 AM Jun Rao  wrote:
>
> > Hi, Justine,
> >
> > Thanks for the reply.
> >
> > 21. What about the new NextProducerId field? Will that be populated with
> TV
> > 1?
> >
> > 22. In the dependencies output, should we show both IV and level for
> > metadata.version too?
> >
> > Jun
> >
> > On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan
>  > >
> > wrote:
> >
> > > Hi Jun,
> > >
> > > 20. I can update the KIP.
> > >
> > > 21. This is used to complete some of the work with KIP-360. (We use
> > > previous producer ID there, but never persisted it which was in the KIP
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820)
> > > The KIP also mentions including previous epoch but we explained in this
> > KIP
> > > how we can figure this out.
> > >
> > > Justine
> > >
> > >
> > >
> > > On Mon, Apr 1, 2024 at 3:56 PM Jun Rao 
> wrote:
> > >
> > > > Hi, Justine,
> > > >
> > > > Thanks for the updated KIP. A couple of more comments.
> > > >
> > > > 20. Could we show the output of version-mapping?
> > > >
> > > > 21. "Transaction version 1 will include the flexible fields in the
> > > > transaction state log, and transaction version 2 will include the
> > changes
> > > > to the transactional protocol as described by KIP-890 (epoch bumps
> and
> > > > implicit add partitions.)"
> > > >   So TV 1 enables the writing of new tagged fields like
> PrevProducerId?
> > > But
> > > > those fields are only usable after the epoch bump, right? What
> > > > functionality does TV 1 achieve?
> > > >
> > > > Jun
> > > >
> > > >
> > > > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
> > >  > > > >
> > > > wrote:
> > > >
> > > > > I have also updated the KIP to mention the feature tool's
> --metadata
> > > flag
> > > > > will be deprecated.
> > > > > It will still work for users as they learn the new flag, but a
> > warning
> > > > > indicating the alternatives will be shown.
> > > > >
> > > > > Justine
> > > > >
> > > > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan <
> > jols...@confluent.io>
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > >
> > > > > > For both transaction state and group coordinator state, there are
> > > only
> > > > > > version 0 records.
> > > > > > KIP-915 introduced flexible versions, but it was never put to
> use.
> > MV
> > > > has
> > > > > > never gated these. This KIP will do that. I can include this
> > context
> > > in
> > > > > the
> > > > > > KIP.
> > > > > >
> > > > > > I'm happy to modify his 1 and 2 to 0 and 1.
> > > > > >
> > > > > > Justine
> > > > > >
> > > > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao
>  > >
> > > > > wrote:
> > > > > >
> > > > > >> Hi, David,
> > > > > >>
> > > > > >> Thanks for the reply.
> > > > > >>
> > > > > >> Historically, the format of all records were controlled by MV.
> > Now,
> > > > > >> records
> > > > > >> in _offset_commit will be controlled by
> > `group.coordinator.version`,
> > > > is
> > > > > >> that right? It would be useful to document that.
> > > > > >>
> > > > > >> Also, we should align on the version numbering. "kafka-feature
> > > > disable"
> > > > > >> says "Disable one or more feature flags. This is the same as
> > > > downgrading
> > > > > >> the version to zero". So, in the `group.coordinator.version'
> case,
> > > we
> > > > > >> probably should use version 0 for the old consumer protocol.
> > > > > >>
> > > > > >> Jun
> > > > > >>
> > > > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
> > > > > >> andrew_schofield_j...@outlook.com> wrote:
> > > > > >>
> > > > > >> > Hi David,
> > > > > >> > I agree that we should use the same mechanism to gate KIP-932
> > once
> > > > > that
> > > > > >> > feature reaches production readiness. The precise details of
> the
> > > > > values
> > > > > >> > will
> > > > > >> > depend upon the current state of all these flags when that
> > release
> > > > > >> comes.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Andrew
> > > > > >> >
> > > > > >> > > On 28 Mar 2024, at 07:11, David Jacot
> > >  > > > >
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > > Hi, Jun, Justine,
> > > > > >> > >
> > > > > >> > > Regarding `group.coordinator.version`, the idea is to use it
> > to
> > > > gate
> > > > > >> > > records and APIs of the group coordinator. The first use
> case
> > > will
> > > > > be
> > > > > >> > > KIP-848. We will use version 2 of the flag to gate all the
> new
> > > > > records
> > > > > >> > and
> > > > > >> > > the new 

[jira] [Created] (KAFKA-16466) QuorumController is swallowing some exception messages

[David Arthur (Jira)]

David Arthur created KAFKA-16466:


 Summary: QuorumController is swallowing some exception messages
 Key: KAFKA-16466
 URL: https://issues.apache.org/jira/browse/KAFKA-16466
 Project: Kafka
  Issue Type: Bug
  Components: controller
Affects Versions: 3.7.0
Reporter: David Arthur
 Fix For: 3.8.0, 3.7.1


In some cases in QuorumController, we throw exceptions from the control manager 
methods. Unless these are explicitly caught and handled, they will eventually 
bubble up to the ControllerReadEvent/ControllerWriteEvent an hit the generic 
error handler.

In the generic error handler of QuorumController, we examine the exception to 
determine if it is a fault or not. In the case where it is not a fault, we log 
the error like:
{code:java}
 log.info("{}: {}", name, failureMessage);
{code}
which results in messages like
{code:java}
[2024-04-02 16:08:38,078] INFO [QuorumController id=3000] registerBroker: event 
failed with UnsupportedVersionException in 167 microseconds. 
(org.apache.kafka.controller.QuorumController:544)
{code}
In this case, the exception actually has more details in its own message
{code:java}
Unable to register because the broker does not support version 8 of 
metadata.version. It wants a version between 20 and 20, inclusive.
{code}

This was found while writing an integration test for KRaft migration where the 
brokers and controllers have a mismatched MetadataVersion.



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

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

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-16465) New consumer does not invoke rebalance callbacks as expected in consumer_test.py system test

[Kirk True (Jira)]

Kirk True created KAFKA-16465:
-

 Summary: New consumer does not invoke rebalance callbacks as 
expected in consumer_test.py system test
 Key: KAFKA-16465
 URL: https://issues.apache.org/jira/browse/KAFKA-16465
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Kirk True
 Fix For: 3.8.0


The {{replication_replica_failure_test.py}} system test fails with the 
following error:

{noformat}
test_id:
kafkatest.tests.core.replication_replica_failure_test.ReplicationReplicaFailureTest.test_replication_with_replica_failure.metadata_quorum=ISOLATED_KRAFT.use_new_coordinator=True.group_protocol=consumer
status: FAIL
run time:   1 minute 20.972 seconds


TimeoutError('Timed out after 30s while awaiting initial record delivery of 
5 records')
Traceback (most recent call last):
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/tests/runner_client.py",
 line 184, in _do_run
data = self.run_test()
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/tests/runner_client.py",
 line 262, in run_test
return self.test_context.function(self.test)
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/mark/_mark.py",
 line 433, in wrapper
return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/tests/kafkatest/tests/core/replication_replica_failure_test.py",
 line 97, in test_replication_with_replica_failure
self.await_startup()
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/tests/kafkatest/tests/end_to_end.py",
 line 125, in await_startup
(timeout_sec, min_records))
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/utils/util.py",
 line 58, in wait_until
raise TimeoutError(err_msg() if callable(err_msg) else err_msg) from 
last_exception
ducktape.errors.TimeoutError: Timed out after 30s while awaiting initial record 
delivery of 5 records
{noformat}



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

[jira] [Created] (KAFKA-16464) New consumer fails with timeout in replication_replica_failure_test.py system test

[Kirk True (Jira)]

Kirk True created KAFKA-16464:
-

 Summary: New consumer fails with timeout in 
replication_replica_failure_test.py system test
 Key: KAFKA-16464
 URL: https://issues.apache.org/jira/browse/KAFKA-16464
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Kirk True
 Fix For: 3.8.0


The {{security_test.py}} system test fails with the following error:

{noformat}
test_id:
kafkatest.tests.core.security_test.SecurityTest.test_client_ssl_endpoint_validation_failure.security_protocol=SSL.interbroker_security_protocol=PLAINTEXT.metadata_quorum=ISOLATED_KRAFT.use_new_coordinator=True.group_protocol=consumer
status: FAIL
run time:   1 minute 30.885 seconds


TimeoutError('')
Traceback (most recent call last):
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/tests/runner_client.py",
 line 184, in _do_run
data = self.run_test()
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/tests/runner_client.py",
 line 262, in run_test
return self.test_context.function(self.test)
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/mark/_mark.py",
 line 433, in wrapper
return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/tests/kafkatest/tests/core/security_test.py",
 line 142, in test_client_ssl_endpoint_validation_failure
wait_until(lambda: self.producer_consumer_have_expected_error(error), 
timeout_sec=30)
  File 
"/home/jenkins/workspace/system-test-kafka-branch-builder/kafka/venv/lib/python3.7/site-packages/ducktape/utils/util.py",
 line 58, in wait_until
raise TimeoutError(err_msg() if callable(err_msg) else err_msg) from 
last_exception
ducktape.errors.TimeoutError
{noformat}



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

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[Justine Olshan]

Hi José

I originally had each on a new line and then switched to a single line
since it looked like a lot of space. I can switch it back.

I don't think it makes a big difference if we implement it for both tools.
Both tools will have use for it.

I can change the name to feature-dependencies if that makes it clearer.

I can say that we won't allow cycles, but I'm not sure the best way to
enforce this.

I just put ">" to show output. I can change the color if that makes it
clearer.

Justine

On Tue, Apr 2, 2024 at 11:41 AM José Armando García Sancio
 wrote:

> Hi Justine,
>
> See my comments below.
>
> On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan
>  wrote:
> > 20. I can update the KIP.
>
> I took a look at the latest KIP.
>
> * Should the output of this command "bin/kafka-features.sh
> version-mapping --release-version 3.6-IV1" be something like this:
> metadata.version=13
> transaction.protocol.version=0
> group.coordinator.version=0
> kraft.version=0
>
> I added the kraft.version to show the changes that are coming from
> KIP-853. I find this formatting much easier to parse by scripts/tools.
> They can even use Java's Properties parser if they want.
>
> * Maybe I missed the discussion but can you talk about why both
> "kafka-storage" and "kafka-features" are going to implement the
> "version-mapping" and dependencies"? I assume that it is sufficient
> for only one (kafka-features) to implement these new commands.
>
> * For the command "dependencies" in the "kafka-features" command, it
> is probably obvious that the dependencies listed are feature version
> dependencies. This is not obvious when the user uses "kafka-storage
> dependencies".  This reads as the dependencies of kafka-storage.
>
> * Should we state that Kafka will not allow cycles in the feature
> version dependency definition? Meaning the user is not allowed to
> define a feature version X which depends on Y which depends on Z which
> depends on X.
>
> * Some of the example output start with the characters "> ". Will the
> CLI print those characters or is that just part of the KIP's
> formating?
>
> Thanks,
> --
> -José
>

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[José Armando García Sancio]

Hi Justine,

See my comments below.

On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan
 wrote:
> 20. I can update the KIP.

I took a look at the latest KIP.

* Should the output of this command "bin/kafka-features.sh
version-mapping --release-version 3.6-IV1" be something like this:
metadata.version=13
transaction.protocol.version=0
group.coordinator.version=0
kraft.version=0

I added the kraft.version to show the changes that are coming from
KIP-853. I find this formatting much easier to parse by scripts/tools.
They can even use Java's Properties parser if they want.

* Maybe I missed the discussion but can you talk about why both
"kafka-storage" and "kafka-features" are going to implement the
"version-mapping" and dependencies"? I assume that it is sufficient
for only one (kafka-features) to implement these new commands.

* For the command "dependencies" in the "kafka-features" command, it
is probably obvious that the dependencies listed are feature version
dependencies. This is not obvious when the user uses "kafka-storage
dependencies".  This reads as the dependencies of kafka-storage.

* Should we state that Kafka will not allow cycles in the feature
version dependency definition? Meaning the user is not allowed to
define a feature version X which depends on Y which depends on Z which
depends on X.

* Some of the example output start with the characters "> ". Will the
CLI print those characters or is that just part of the KIP's
formating?

Thanks,
-- 
-José

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[Justine Olshan]

Jun,

21. Next producer ID field doesn't need to be populated for TV 1. We don't
have the same need to retain this since it is written directly to the
transaction log in InitProducerId. It is only needed for KIP-890 part 2 /
TV 2.

22. We can do that.

Justine

On Tue, Apr 2, 2024 at 10:41 AM Jun Rao  wrote:

> Hi, Justine,
>
> Thanks for the reply.
>
> 21. What about the new NextProducerId field? Will that be populated with TV
> 1?
>
> 22. In the dependencies output, should we show both IV and level for
> metadata.version too?
>
> Jun
>
> On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan  >
> wrote:
>
> > Hi Jun,
> >
> > 20. I can update the KIP.
> >
> > 21. This is used to complete some of the work with KIP-360. (We use
> > previous producer ID there, but never persisted it which was in the KIP
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820)
> > The KIP also mentions including previous epoch but we explained in this
> KIP
> > how we can figure this out.
> >
> > Justine
> >
> >
> >
> > On Mon, Apr 1, 2024 at 3:56 PM Jun Rao  wrote:
> >
> > > Hi, Justine,
> > >
> > > Thanks for the updated KIP. A couple of more comments.
> > >
> > > 20. Could we show the output of version-mapping?
> > >
> > > 21. "Transaction version 1 will include the flexible fields in the
> > > transaction state log, and transaction version 2 will include the
> changes
> > > to the transactional protocol as described by KIP-890 (epoch bumps and
> > > implicit add partitions.)"
> > >   So TV 1 enables the writing of new tagged fields like PrevProducerId?
> > But
> > > those fields are only usable after the epoch bump, right? What
> > > functionality does TV 1 achieve?
> > >
> > > Jun
> > >
> > >
> > > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
> >  > > >
> > > wrote:
> > >
> > > > I have also updated the KIP to mention the feature tool's --metadata
> > flag
> > > > will be deprecated.
> > > > It will still work for users as they learn the new flag, but a
> warning
> > > > indicating the alternatives will be shown.
> > > >
> > > > Justine
> > > >
> > > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan <
> jols...@confluent.io>
> > > > wrote:
> > > >
> > > > > Hi Jun,
> > > > >
> > > > > For both transaction state and group coordinator state, there are
> > only
> > > > > version 0 records.
> > > > > KIP-915 introduced flexible versions, but it was never put to use.
> MV
> > > has
> > > > > never gated these. This KIP will do that. I can include this
> context
> > in
> > > > the
> > > > > KIP.
> > > > >
> > > > > I'm happy to modify his 1 and 2 to 0 and 1.
> > > > >
> > > > > Justine
> > > > >
> > > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao  >
> > > > wrote:
> > > > >
> > > > >> Hi, David,
> > > > >>
> > > > >> Thanks for the reply.
> > > > >>
> > > > >> Historically, the format of all records were controlled by MV.
> Now,
> > > > >> records
> > > > >> in _offset_commit will be controlled by
> `group.coordinator.version`,
> > > is
> > > > >> that right? It would be useful to document that.
> > > > >>
> > > > >> Also, we should align on the version numbering. "kafka-feature
> > > disable"
> > > > >> says "Disable one or more feature flags. This is the same as
> > > downgrading
> > > > >> the version to zero". So, in the `group.coordinator.version' case,
> > we
> > > > >> probably should use version 0 for the old consumer protocol.
> > > > >>
> > > > >> Jun
> > > > >>
> > > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
> > > > >> andrew_schofield_j...@outlook.com> wrote:
> > > > >>
> > > > >> > Hi David,
> > > > >> > I agree that we should use the same mechanism to gate KIP-932
> once
> > > > that
> > > > >> > feature reaches production readiness. The precise details of the
> > > > values
> > > > >> > will
> > > > >> > depend upon the current state of all these flags when that
> release
> > > > >> comes.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Andrew
> > > > >> >
> > > > >> > > On 28 Mar 2024, at 07:11, David Jacot
> >  > > >
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > Hi, Jun, Justine,
> > > > >> > >
> > > > >> > > Regarding `group.coordinator.version`, the idea is to use it
> to
> > > gate
> > > > >> > > records and APIs of the group coordinator. The first use case
> > will
> > > > be
> > > > >> > > KIP-848. We will use version 2 of the flag to gate all the new
> > > > records
> > > > >> > and
> > > > >> > > the new ConsumerGroupHeartbeat/Describe APIs present in AK
> 3.8.
> > So
> > > > >> > version
> > > > >> > > 1 will be the only the old protocol and version 2 will be the
> > > > >> currently
> > > > >> > > implemented new protocol. I don't think that we have any
> > > dependency
> > > > on
> > > > >> > the
> > > > >> > > metadata version at the moment. The changes are orthogonal. I
> > > think
> > > > >> that
> > > > >> > we
> > > > >> > > could mention KIP-848 as the first usage of this flag in the
> > KIP.
> > > I
> > > > >> will
> > > > >> > > also update KIP-848 to include 

[jira] [Created] (KAFKA-16463) Automatically delete metadata log directory on ZK brokers

[David Arthur (Jira)]

David Arthur created KAFKA-16463:


 Summary: Automatically delete metadata log directory on ZK brokers
 Key: KAFKA-16463
 URL: https://issues.apache.org/jira/browse/KAFKA-16463
 Project: Kafka
  Issue Type: Improvement
Reporter: David Arthur
Assignee: David Arthur
 Fix For: 3.8.0


Throughout the process of a ZK to KRaft migration, the operator has the choice 
to revert back to ZK mode. Once this is done, there will be a copy of the 
metadata log on each broker in the cluster.

In order to re-attempt the migration in the future, this metadata log needs to 
be deleted. This can be pretty burdensome to the operator for large clusters. 

To improve this, we can automatically delete any metadata log present during 
startup of a ZK broker. This is safe to do because the ZK broker will just 
re-replicate the metadata log from the active controller.



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

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[Jun Rao]

Hi, Justine,

Thanks for the reply.

21. What about the new NextProducerId field? Will that be populated with TV
1?

22. In the dependencies output, should we show both IV and level for
metadata.version too?

Jun

On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan 
wrote:

> Hi Jun,
>
> 20. I can update the KIP.
>
> 21. This is used to complete some of the work with KIP-360. (We use
> previous producer ID there, but never persisted it which was in the KIP
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820)
> The KIP also mentions including previous epoch but we explained in this KIP
> how we can figure this out.
>
> Justine
>
>
>
> On Mon, Apr 1, 2024 at 3:56 PM Jun Rao  wrote:
>
> > Hi, Justine,
> >
> > Thanks for the updated KIP. A couple of more comments.
> >
> > 20. Could we show the output of version-mapping?
> >
> > 21. "Transaction version 1 will include the flexible fields in the
> > transaction state log, and transaction version 2 will include the changes
> > to the transactional protocol as described by KIP-890 (epoch bumps and
> > implicit add partitions.)"
> >   So TV 1 enables the writing of new tagged fields like PrevProducerId?
> But
> > those fields are only usable after the epoch bump, right? What
> > functionality does TV 1 achieve?
> >
> > Jun
> >
> >
> > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
>  > >
> > wrote:
> >
> > > I have also updated the KIP to mention the feature tool's --metadata
> flag
> > > will be deprecated.
> > > It will still work for users as they learn the new flag, but a warning
> > > indicating the alternatives will be shown.
> > >
> > > Justine
> > >
> > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan 
> > > wrote:
> > >
> > > > Hi Jun,
> > > >
> > > > For both transaction state and group coordinator state, there are
> only
> > > > version 0 records.
> > > > KIP-915 introduced flexible versions, but it was never put to use. MV
> > has
> > > > never gated these. This KIP will do that. I can include this context
> in
> > > the
> > > > KIP.
> > > >
> > > > I'm happy to modify his 1 and 2 to 0 and 1.
> > > >
> > > > Justine
> > > >
> > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao 
> > > wrote:
> > > >
> > > >> Hi, David,
> > > >>
> > > >> Thanks for the reply.
> > > >>
> > > >> Historically, the format of all records were controlled by MV. Now,
> > > >> records
> > > >> in _offset_commit will be controlled by `group.coordinator.version`,
> > is
> > > >> that right? It would be useful to document that.
> > > >>
> > > >> Also, we should align on the version numbering. "kafka-feature
> > disable"
> > > >> says "Disable one or more feature flags. This is the same as
> > downgrading
> > > >> the version to zero". So, in the `group.coordinator.version' case,
> we
> > > >> probably should use version 0 for the old consumer protocol.
> > > >>
> > > >> Jun
> > > >>
> > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
> > > >> andrew_schofield_j...@outlook.com> wrote:
> > > >>
> > > >> > Hi David,
> > > >> > I agree that we should use the same mechanism to gate KIP-932 once
> > > that
> > > >> > feature reaches production readiness. The precise details of the
> > > values
> > > >> > will
> > > >> > depend upon the current state of all these flags when that release
> > > >> comes.
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> > > On 28 Mar 2024, at 07:11, David Jacot
>  > >
> > > >> > wrote:
> > > >> > >
> > > >> > > Hi, Jun, Justine,
> > > >> > >
> > > >> > > Regarding `group.coordinator.version`, the idea is to use it to
> > gate
> > > >> > > records and APIs of the group coordinator. The first use case
> will
> > > be
> > > >> > > KIP-848. We will use version 2 of the flag to gate all the new
> > > records
> > > >> > and
> > > >> > > the new ConsumerGroupHeartbeat/Describe APIs present in AK 3.8.
> So
> > > >> > version
> > > >> > > 1 will be the only the old protocol and version 2 will be the
> > > >> currently
> > > >> > > implemented new protocol. I don't think that we have any
> > dependency
> > > on
> > > >> > the
> > > >> > > metadata version at the moment. The changes are orthogonal. I
> > think
> > > >> that
> > > >> > we
> > > >> > > could mention KIP-848 as the first usage of this flag in the
> KIP.
> > I
> > > >> will
> > > >> > > also update KIP-848 to include it when this KIP is accepted.
> > Another
> > > >> use
> > > >> > > case is the Queues KIP. I think that we should also use this new
> > > flag
> > > >> to
> > > >> > > gate it.
> > > >> > >
> > > >> > > Best,
> > > >> > > David
> > > >> > >
> > > >> > > On Thu, Mar 28, 2024 at 1:14 AM Jun Rao
>  > >
> > > >> > wrote:
> > > >> > >
> > > >> > >> Hi, Justine,
> > > >> > >>
> > > >> > >> Thanks for the reply.
> > > >> > >>
> > > >> > >> So, "dependencies" and "version-mapping" will be added to both
> > > >> > >> kafka-feature and kafka-storage? Could we document that in the
> > tool
> > > >> > format
> > > >> > >> section?
> > > >> > >>
> > > >> > >> Jun
> 

[jira] [Created] (KAFKA-16462) New consumer fails with timeout in security_test.py system test

[Kirk True (Jira)]

Kirk True created KAFKA-16462:
-

 Summary: New consumer fails with timeout in security_test.py 
system test
 Key: KAFKA-16462
 URL: https://issues.apache.org/jira/browse/KAFKA-16462
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Kirk True
 Fix For: 3.8.0


The {{security_test.py}} system test fails with the following error:

{quote}
* Consumer failed to consume up to offsets
{quote}

Affected test:

* {{test_client_ssl_endpoint_validation_failure}}



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

[jira] [Created] (KAFKA-16461) New consumer fails to consume records in security_test.py system test

[Kirk True (Jira)]

Kirk True created KAFKA-16461:
-

 Summary: New consumer fails to consume records in security_test.py 
system test
 Key: KAFKA-16461
 URL: https://issues.apache.org/jira/browse/KAFKA-16461
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Kirk True
 Fix For: 3.8.0


The {{consumer_test.py}} system test fails with the following errors:

{quote}
* Timed out waiting for consumption
{quote}

Affected tests:

* {{test_broker_failure}}
* {{test_consumer_bounce}}
* {{test_static_consumer_bounce}}



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

[jira] [Created] (KAFKA-16460) New consumer times out system test

[Kirk True (Jira)]

Kirk True created KAFKA-16460:
-

 Summary: New consumer times out system test
 Key: KAFKA-16460
 URL: https://issues.apache.org/jira/browse/KAFKA-16460
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Kirk True
 Fix For: 3.8.0


The {{consumer_test.py}} system test fails with two different errors related to 
consumers joining the consumer group in a timely fashion.

{quote}
* Consumers failed to join in a reasonable amount of time
* Timed out waiting for consumers to join, expected total X joined, but only 
see Y joined fromnormal consumer group and Z from conflict consumer group{quote}

Affected tests:

 * {{test_fencing_static_consumer}}
 * {{test_static_consumer_bounce}}
 * {{test_static_consumer_persisted_after_rejoin}}



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

[jira] [Created] (KAFKA-16459) consumer_test.py’s static membership tests fail with new consumer

[Kirk True (Jira)]

Kirk True created KAFKA-16459:
-

 Summary: consumer_test.py’s static membership tests fail with new 
consumer
 Key: KAFKA-16459
 URL: https://issues.apache.org/jira/browse/KAFKA-16459
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer, system tests
Affects Versions: 3.7.0
Reporter: Kirk True
Assignee: Philip Nee
 Fix For: 3.8.0


The following error is reported when running the {{test_valid_assignment}} test 
from {{consumer_test.py}}:

 {code}
Traceback (most recent call last):
  File 
"/usr/local/lib/python3.9/dist-packages/ducktape/tests/runner_client.py", line 
186, in _do_run
data = self.run_test()
  File 
"/usr/local/lib/python3.9/dist-packages/ducktape/tests/runner_client.py", line 
246, in run_test
return self.test_context.function(self.test)
  File "/usr/local/lib/python3.9/dist-packages/ducktape/mark/_mark.py", line 
433, in wrapper
return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
  File "/opt/kafka-dev/tests/kafkatest/tests/client/consumer_test.py", line 
584, in test_valid_assignment
wait_until(lambda: self.valid_assignment(self.TOPIC, self.NUM_PARTITIONS, 
consumer.current_assignment()),
  File "/usr/local/lib/python3.9/dist-packages/ducktape/utils/util.py", line 
58, in wait_until
raise TimeoutError(err_msg() if callable(err_msg) else err_msg) from 
last_exception
ducktape.errors.TimeoutError: expected valid assignments of 6 partitions when 
num_started 2: [('ducker@ducker05', []), ('ducker@ducker06', [])]
{code}

To reproduce, create a system test suite file named 
{{test_valid_assignment.yml}} with these contents:

{code:yaml}
failures:
  - 
'kafkatest/tests/client/consumer_test.py::AssignmentValidationTest.test_valid_assignment@{"metadata_quorum":"ISOLATED_KRAFT","use_new_coordinator":true,"group_protocol":"consumer","group_remote_assignor":"range"}'
{code}

Then set the the {{TC_PATHS}} environment variable to include that test suite 
file.



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

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: [DISCUSS] KIP-932: Queues for Kafka

[Andrew Schofield]

Hi Omnia,
Thanks for your questions.

The DR angle on `group.type` is interesting and I had not considered it. The 
namespace of groups contains
both consumer groups and share groups, so I was trying to ensure that which 
group type was used was
deterministic rather than a race to create the first member. There are already 
other uses of the group protocol
such as Kafka Connect, so it’s all a bit confusing even today.

It is actually KIP-848 which introduces configurations for group resources and 
KIP-932 is just building on
the idea. I think that MM2 will need to sync these configurations. The question 
of whether `group.type` is
a sensible configuration I think is separate.

Imagine that we do have `group.type` as a group configuration. How would we end 
up with groups with
the same ID but different types on the two ends of MM2? Assuming that both ends 
have KIP-932 enabled,
either the configuration was not set, and a consumer group was made on one end 
while a share group was
made on the other, OR, the configuration was set but its value changed, and 
again we get a divergence.

I think that on balance, having `group.type` as a configuration does at least 
mean there’s a better chance that
the two ends of MM2 do agree on the type of group. I’m happy to consider other 
ways to do this better. The
fact that we have different kinds of group in the same namespace is the tricky 
thing. I think this was possible
before this KIP, but it’s much more likely now.


Onto the question of memory. There are several different parts to this, all of 
which are distributed across
the cluster.

* For the group coordinator, the memory consumption will be affected by the 
number of groups,
the number of members and the number of topic-partitions to be assigned to the 
members. The
group coordinator is concerned with membership and assignment, so the memory 
per topic-partition
will be small.
* For the share coordinator, the memory consumption will be affected by the 
number of groups, the
number of topic-partitions being consumed in the group, and the number of 
in-flight records, but not
the number of members. We should be talking about no more than kilobytes per 
topic-partition.
* For the share-partition leader, the memory consumption will be affected by 
the number of share group
members assigned the topic-partition and the number of in-flight records. 
Again, we should be talking
about no more than kilobytes per topic-partition.

Of these, the factor that is not directly under control is the number of 
topic-partitions. The reason is that
I wanted to avoid a situation where the number of partitions in a topic was 
increased and suddenly
consumption in a share group hit a limit that was not anticipated.

I could introduce a configuration for controlling the number of topics allowed 
to be subscribed in a share
group. Personally, I think 1 would be a good starting point.

Let me know what you think.

Thanks,
Andrew


> On 2 Apr 2024, at 15:39, Omnia Ibrahim  wrote:
> 
> Hi Andrew, 
> Thanks for the KIP it is definitely an interesting read. I have few questions 
> As the KIP proposing extending `AdminClient.incrementalAlterConfigs` to add 
> an explicit `group.type` what would this means for DR feature in MM2 
> offering? 
> Right now MM2 sync consumer group offsets from source to destination cluster. 
> And it also offer sync ACLs which contribute to DR feature. Would this KIP 
> means MM2 needs to also sync the type of groups to destination? 
> As `AdminClient.incrementalAlterConfigs` means "when a new group is created 
> with this name, it must have this type”. What will happened if clusters on 
> both ends of MM2 has same group id but with different types? 
> If this concern is out of the scope we might need to call this out somewhere 
> in the KIP. 
> While the number of share-group and the number of consumers in share-group is 
> limited by `group.share.max.groups`and `group.share.max.size` the total 
> number of share-group state records that might need to be loaded in-memeory 
> has another factor which is the number of partitions. In cases where group is 
> consuming from large number of topics with large number of partitions what 
> will be the impact on coordinator memory?
> 
> Thanks 
> Omnia
> 
> 
>> On 25 Mar 2024, at 10:23, Andrew Schofield 
>>  wrote:
>> 
>> Hi Justine,
>> Thanks for your questions.
>> 
>> There are several limits in this KIP. With consumer groups, we see problems
>> where there are huge numbers of consumer groups, and we also see problems
>> when there are huge number of members in a consumer group.
>> 
>> There’s a limit on the number of members in share group. When the limit is 
>> reached,
>> additional members are not admitted to the group. The members heartbeat to 
>> remain
>> in the group and that enables timely expiration.
>> 
>> There’s also a limit of the number of share groups in a cluster. Initially, 
>> this limit has been
>> set low. As a result, it would be possible to 

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

[Apache Jenkins Server]

See 

Re: [PR] MINOR: update 3.6 [kafka-site]

[via GitHub]

wcarlson5 merged PR #593:
URL: https://github.com/apache/kafka-site/pull/593


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

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

[Omnia Ibrahim]

Hi Andrew, 
Thanks for the KIP it is definitely an interesting read. I have few questions 
As the KIP proposing extending `AdminClient.incrementalAlterConfigs` to add an 
explicit `group.type` what would this means for DR feature in MM2 offering? 
Right now MM2 sync consumer group offsets from source to destination cluster. 
And it also offer sync ACLs which contribute to DR feature. Would this KIP 
means MM2 needs to also sync the type of groups to destination? 
As `AdminClient.incrementalAlterConfigs` means "when a new group is created 
with this name, it must have this type”. What will happened if clusters on both 
ends of MM2 has same group id but with different types? 
If this concern is out of the scope we might need to call this out somewhere in 
the KIP. 
While the number of share-group and the number of consumers in share-group is 
limited by `group.share.max.groups`and `group.share.max.size` the total number 
of share-group state records that might need to be loaded in-memeory has 
another factor which is the number of partitions. In cases where group is 
consuming from large number of topics with large number of partitions what will 
be the impact on coordinator memory?

Thanks 
Omnia


> On 25 Mar 2024, at 10:23, Andrew Schofield 
>  wrote:
> 
> Hi Justine,
> Thanks for your questions.
> 
> There are several limits in this KIP. With consumer groups, we see problems
> where there are huge numbers of consumer groups, and we also see problems
> when there are huge number of members in a consumer group.
> 
> There’s a limit on the number of members in share group. When the limit is 
> reached,
> additional members are not admitted to the group. The members heartbeat to 
> remain
> in the group and that enables timely expiration.
> 
> There’s also a limit of the number of share groups in a cluster. Initially, 
> this limit has been
> set low. As a result, it would be possible to create sufficient groups to 
> reach the limit,
> and then creating additional groups will fail. It will be possible to delete 
> a share group
> administratively, but share groups do not automatically expire (just like 
> topics do not
> expire and queues in message-queuing systems do not expire).
> 
> The `kafka-console-share-consumer.sh` tool in the KIP defaults the group name 
> to
> “share”. This has two benefits. First, it means that the trivial exploratory 
> use of it running
> multiple concurrent copies will naturally get sharing of the records consumed.
> Second, it means that only one share group is being create, rather than 
> generating another
> group ID for each execution.
> 
> Please do re-read the read-committed section. I’ll grateful for all the 
> thoughtful reviews
> that the community is able to provide. The KIP says that broker-side filtering
> removes the records for aborted transactions. This is obviously quite a 
> difference compared
> with consumers in consumer groups. It think it would also be possible to do 
> it client-side
> but the records fetched from the replica manager are distributed among the 
> consumers,
> and I’m concerned that it would be difficult to distribute the list of 
> aborted transactions
> relevant to the records each consumer receives. I’m considering prototyping 
> client-side
> filtering to see how well it works in practice.
> 
> I am definitely thoughtful about the inter-broker hops in order to persist 
> the share-group
> state. Originally, I did look at writing the state directly into the user’s 
> topic-partitions
> because this means the share-partition leader would be able to write directly.
> This has downsides as documented in the “Rejected Alternatives” section of 
> the KIP.
> 
> We do have opportunities for pipelining and batching which I expect we will 
> exploit
> in order to improve the performance.
> 
> This KIP is only the beginning. I expect a future KIP will address storage of 
> metadata
> in a more performant way.
> 
> Thanks,
> Andrew
> 
>> On 21 Mar 2024, at 15:40, Justine Olshan  
>> wrote:
>> 
>> Thanks Andrew,
>> 
>> That answers some of the questions I have.
>> 
>> With respect to the limits -- how will this be implemented? One issue we
>> saw with producers is "short-lived" producers that send one message and
>> disconnect.
>> Due to how expiration works for producer state, if we have a simple limit
>> for producer IDs, all new producers are blocked until the old ones expire.
>> Will we block new group members as well if we reach our limit?
>> 
>> In the consumer case, we have a heartbeat which can be used for expiration
>> behavior and avoid the headache we see on the producer side, but I can
>> imagine a case where misuse of the groups themselves could occur -- ie
>> creating a short lived share group that I believe will take some time to
>> expire. Do we have considerations for this case?
>> 
>> I also plan to re-read the read-committed section and may have further
>> questions there.
>> 
>> You also mentioned in the KIP how there are a few 

Re: [DISCUSS] KIP-1024: Make the restore behavior of GlobalKTables with custom processors configureable

[Matthias J. Sax]

One more thing:

I was just looking into the WIP PR, and it seems we will also need to 
change `StreamsBuilder.scala`. The KIP needs to cover this changes as well.



-Matthias

On 4/1/24 10:33 PM, Bruno Cadonna wrote:

Hi Walker and Matthias,

(2)
That is exactly my point about having a compile time error versus a 
runtime error. The added flexibility as proposed by Matthias sounds good 
to me.


Regarding the Named parameter, I was not aware that the processor that 
writes records to the global state store is named according to the name 
passed in by Consumed. I thought Consumed strictly specifies the names 
of source processors. So I am fine with not having an overload with a 
Named parameter.


Best,
Bruno

On 3/31/24 11:30 AM, Matthias J. Sax wrote:

Two more follow up thoughts:

(1) I am still not a big fan of the boolean parameter we introduce. 
Did you consider to use different method names, like 
`addReadOnlyGlobalStore()` (for the optimized method, that would not 
reprocess data on restore), and maybe add `addModifiableGlobalStore()` 
(not a good name, but we cannot re-use existing `addGlobalStore()` -- 
maybe somebody else has a good idea about a better `addXxxGlobalStore` 
that would describe it well).


(2) I was thinking about Bruno's comment to limit the scope the store 
builder for the optimized case. I think we should actually do 
something about it, because in the end, the runtime (ie, the 
`Processor` we hard wire) would need to pick a store it supports and 
cast to the corresponding store? If the cast fails, we hit a runtime 
exception, but by putting the store we cast to into the signature we 
can actually convert it into a compile time error what seems better. 
-- If we want, we could make it somewhat flexible and support both 
`KeyValueStore` and `TimestampedKeyValueStore` -- ie, the signature 
would be `KeyValueStore` but we explicitly check if the builder gives 
us a `TimestampedKeyValueStore` instance and use it properly.


If putting the signature does not work for some reason, we should at 
least clearly call it out in the JavaDocs what store type is expected.




-Matthias



On 3/28/24 5:05 PM, Walker Carlson wrote:

Hey all,

Thanks for the feedback Bruno, Almog and Matthias!

Almog: I like the idea, but I agree with Matthais. I actually looked at
that ticket a bit when doing this and found that while similar they are
actually pretty unrelated codewise. I would love to see it get taken 
care

of.

Bruno and Matthias: The Named parameter doesn't really make sense to 
me to
put it here. The store in the Store builder is already named through 
what

Matthais described and the processor doesn't actually have a name. That
would be the processor node that gets named via the Named parameter  (in
the DSL) and the internal streams builder uses the consumed object to 
make

a source name. I think we should just keep the Consumed object and used
that for the processor node name.

As for the limitation of the store builder interface I don't think it is
necessary. It could be something we add later if we really want to.

Anyways I think we are getting close enough to consensus that I'm 
going to

open a vote and hopefully we can get it voted on soon!

best,
Walker

On Thu, Mar 28, 2024 at 5:55 AM Matthias J. Sax  
wrote:



Hey,

looking into the API, I am wondering why we would need to add an
overload talking a `Named` parameter?

StreamsBuilder.addGlobalStore() (and .addGlobalTable()) already takes a
`Consumed` parameter that allows to set a name.



2.
I do not understand what you mean with "maximum flexibility". The

built-in processor needs to assume a given state store interface. That
means, users have to provide a state store that offers that 
interface. If

they do not they will get a runtime exception. If we require a store
builder for a given interface, we can catch the mistake at compile 
time.

Let me know whether I misunderstood something.

Yes, we could catch it at runtime. But I guess what I was trying to say
is different: I was trying to say, we should not limit the API to 
always

require a specific store, such that global stores can only be of a
certain type. Global Stores should be allowed to be of any type. Hence,
if we add a built-in processor, it can only be one option, and we 
always

need to support custom processor, and might also want to try to allow
the restore optimization for custom processor (and thus other store
types), not just for our built-in processor (and our built-in stores).
Coupling the optimization to built-in stores would prevent us to apply
the optimization to custom stores.



@Almog: interesting idea. I tend to think that both issues are
orthogonal. If users pick to apply the optimization "added" by this 
KIP,

the bug you mentioned would still apply to global stores, and thus this
KIP is not addressing the issue you mentioned.

Personally, I also think that we don't need a KIP to fix the ticket you
mentioned? In the end, we need to skip 

[jira] [Created] (KAFKA-16458) Add contains method in KeyValue store interface

[Ayoub Omari (Jira)]

Ayoub Omari created KAFKA-16458:
---

 Summary: Add contains method in KeyValue store interface
 Key: KAFKA-16458
 URL: https://issues.apache.org/jira/browse/KAFKA-16458
 Project: Kafka
  Issue Type: Wish
  Components: streams
Reporter: Ayoub Omari


In some stream processors, we sometimes just want to check if a key exists in 
the state store or not.

 

I find calling .get() and checking if the return value is null a little bit 
verbose
{code:java}
if (store.get(key) != null) {

}{code}
 

But I am not sure if it is on purpose that we would like to keep the store 
interface simple.



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

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

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-16457) Useless import class

[Svyatoslav (Jira)]

Svyatoslav created KAFKA-16457:
--

 Summary: Useless import class
 Key: KAFKA-16457
 URL: https://issues.apache.org/jira/browse/KAFKA-16457
 Project: Kafka
  Issue Type: Task
  Components: config
Affects Versions: 3.7.0
Reporter: Svyatoslav


Useless import class in SslConfigs.java

 
{code:java}
import org.apache.kafka.common.config.ConfigDef.Type;

.define(SslConfigs.SSL_KEYSTORE_KEY_CONFIG, Type.PASSWORD, null,  
ConfigDef.Importance.HIGH, SslConfigs.SSL_KEYSTORE_KEY_DOC){code}
 

 



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

[jira] [Resolved] (KAFKA-16148) Implement GroupMetadataManager#onUnloaded

[David Jacot (Jira)]

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

David Jacot resolved KAFKA-16148.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

> Implement GroupMetadataManager#onUnloaded
> -
>
> Key: KAFKA-16148
> URL: https://issues.apache.org/jira/browse/KAFKA-16148
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Jeff Kim
>Assignee: Jeff Kim
>Priority: Major
> Fix For: 3.8.0
>
>
> complete all awaiting futures with NOT_COORDINATOR (for classic group)
> transition all groups to DEAD.
> Cancel all timers related to the unloaded group metadata manager



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

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[David Jacot]

Hi Justine,

Thanks for the KIP. This will be very helpful!

I do have one question regarding the naming of the new flags which is not
totally clear in the KIP. It would be great if we could call them out in
the Public Interfaces section.

My understanding is that the KIP proposes to use
`transaction.protocol.version` and `group.coordinator.version`. I was
wondering whether we should just use `transaction.version` and
`group.version`. The rationale for the first one is that a new version may
not always be for a protocol change. The rationale for the second one is
that it gates more than the group coordinator as we may use it for queues
too. It would also be aligned with `metadata.version`. I apologize if this
was already discussed.

Best,
David


On Tue, Apr 2, 2024 at 11:18 AM David Jacot  wrote:

> Hi Jun,
>
> > Historically, the format of all records were controlled by MV. Now,
> records
> in _offset_commit will be controlled by `group.coordinator.version`, is
> that right? It would be useful to document that.
>
> Yes. This is correct. The idea is to replace the MV with this new flag. It
> will have the same semantics but with the benefit of being independent.
>
> > Also, we should align on the version numbering. "kafka-feature disable"
> says "Disable one or more feature flags. This is the same as downgrading
> the version to zero". So, in the `group.coordinator.version' case, we
> probably should use version 0 for the old consumer protocol.
>
> This makes sense. We can definitely use version 0.
>
> Best,
> David
>
> On Tue, Apr 2, 2024 at 1:43 AM Justine Olshan 
> wrote:
>
>> Hi Jun,
>>
>> 20. I can update the KIP.
>>
>> 21. This is used to complete some of the work with KIP-360. (We use
>> previous producer ID there, but never persisted it which was in the KIP
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820
>> )
>> The KIP also mentions including previous epoch but we explained in this
>> KIP
>> how we can figure this out.
>>
>> Justine
>>
>>
>>
>> On Mon, Apr 1, 2024 at 3:56 PM Jun Rao  wrote:
>>
>> > Hi, Justine,
>> >
>> > Thanks for the updated KIP. A couple of more comments.
>> >
>> > 20. Could we show the output of version-mapping?
>> >
>> > 21. "Transaction version 1 will include the flexible fields in the
>> > transaction state log, and transaction version 2 will include the
>> changes
>> > to the transactional protocol as described by KIP-890 (epoch bumps and
>> > implicit add partitions.)"
>> >   So TV 1 enables the writing of new tagged fields like PrevProducerId?
>> But
>> > those fields are only usable after the epoch bump, right? What
>> > functionality does TV 1 achieve?
>> >
>> > Jun
>> >
>> >
>> > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
>> > > >
>> > wrote:
>> >
>> > > I have also updated the KIP to mention the feature tool's --metadata
>> flag
>> > > will be deprecated.
>> > > It will still work for users as they learn the new flag, but a warning
>> > > indicating the alternatives will be shown.
>> > >
>> > > Justine
>> > >
>> > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan > >
>> > > wrote:
>> > >
>> > > > Hi Jun,
>> > > >
>> > > > For both transaction state and group coordinator state, there are
>> only
>> > > > version 0 records.
>> > > > KIP-915 introduced flexible versions, but it was never put to use.
>> MV
>> > has
>> > > > never gated these. This KIP will do that. I can include this
>> context in
>> > > the
>> > > > KIP.
>> > > >
>> > > > I'm happy to modify his 1 and 2 to 0 and 1.
>> > > >
>> > > > Justine
>> > > >
>> > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao 
>> > > wrote:
>> > > >
>> > > >> Hi, David,
>> > > >>
>> > > >> Thanks for the reply.
>> > > >>
>> > > >> Historically, the format of all records were controlled by MV. Now,
>> > > >> records
>> > > >> in _offset_commit will be controlled by
>> `group.coordinator.version`,
>> > is
>> > > >> that right? It would be useful to document that.
>> > > >>
>> > > >> Also, we should align on the version numbering. "kafka-feature
>> > disable"
>> > > >> says "Disable one or more feature flags. This is the same as
>> > downgrading
>> > > >> the version to zero". So, in the `group.coordinator.version' case,
>> we
>> > > >> probably should use version 0 for the old consumer protocol.
>> > > >>
>> > > >> Jun
>> > > >>
>> > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
>> > > >> andrew_schofield_j...@outlook.com> wrote:
>> > > >>
>> > > >> > Hi David,
>> > > >> > I agree that we should use the same mechanism to gate KIP-932
>> once
>> > > that
>> > > >> > feature reaches production readiness. The precise details of the
>> > > values
>> > > >> > will
>> > > >> > depend upon the current state of all these flags when that
>> release
>> > > >> comes.
>> > > >> >
>> > > >> > Thanks,
>> > > >> > Andrew
>> > > >> >
>> > > >> > > On 28 Mar 2024, at 07:11, David Jacot
>> > > >
>> > > >> > wrote:
>> > > >> > >
>> > > >> > > Hi, Jun, Justine,
>> > > >> > >
>> > > >> > > Regarding 

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

[David Jacot]

Hi Jun,

> Historically, the format of all records were controlled by MV. Now,
records
in _offset_commit will be controlled by `group.coordinator.version`, is
that right? It would be useful to document that.

Yes. This is correct. The idea is to replace the MV with this new flag. It
will have the same semantics but with the benefit of being independent.

> Also, we should align on the version numbering. "kafka-feature disable"
says "Disable one or more feature flags. This is the same as downgrading
the version to zero". So, in the `group.coordinator.version' case, we
probably should use version 0 for the old consumer protocol.

This makes sense. We can definitely use version 0.

Best,
David

On Tue, Apr 2, 2024 at 1:43 AM Justine Olshan 
wrote:

> Hi Jun,
>
> 20. I can update the KIP.
>
> 21. This is used to complete some of the work with KIP-360. (We use
> previous producer ID there, but never persisted it which was in the KIP
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89068820)
> The KIP also mentions including previous epoch but we explained in this KIP
> how we can figure this out.
>
> Justine
>
>
>
> On Mon, Apr 1, 2024 at 3:56 PM Jun Rao  wrote:
>
> > Hi, Justine,
> >
> > Thanks for the updated KIP. A couple of more comments.
> >
> > 20. Could we show the output of version-mapping?
> >
> > 21. "Transaction version 1 will include the flexible fields in the
> > transaction state log, and transaction version 2 will include the changes
> > to the transactional protocol as described by KIP-890 (epoch bumps and
> > implicit add partitions.)"
> >   So TV 1 enables the writing of new tagged fields like PrevProducerId?
> But
> > those fields are only usable after the epoch bump, right? What
> > functionality does TV 1 achieve?
> >
> > Jun
> >
> >
> > On Mon, Apr 1, 2024 at 2:06 PM Justine Olshan
>  > >
> > wrote:
> >
> > > I have also updated the KIP to mention the feature tool's --metadata
> flag
> > > will be deprecated.
> > > It will still work for users as they learn the new flag, but a warning
> > > indicating the alternatives will be shown.
> > >
> > > Justine
> > >
> > > On Thu, Mar 28, 2024 at 11:03 AM Justine Olshan 
> > > wrote:
> > >
> > > > Hi Jun,
> > > >
> > > > For both transaction state and group coordinator state, there are
> only
> > > > version 0 records.
> > > > KIP-915 introduced flexible versions, but it was never put to use. MV
> > has
> > > > never gated these. This KIP will do that. I can include this context
> in
> > > the
> > > > KIP.
> > > >
> > > > I'm happy to modify his 1 and 2 to 0 and 1.
> > > >
> > > > Justine
> > > >
> > > > On Thu, Mar 28, 2024 at 10:57 AM Jun Rao 
> > > wrote:
> > > >
> > > >> Hi, David,
> > > >>
> > > >> Thanks for the reply.
> > > >>
> > > >> Historically, the format of all records were controlled by MV. Now,
> > > >> records
> > > >> in _offset_commit will be controlled by `group.coordinator.version`,
> > is
> > > >> that right? It would be useful to document that.
> > > >>
> > > >> Also, we should align on the version numbering. "kafka-feature
> > disable"
> > > >> says "Disable one or more feature flags. This is the same as
> > downgrading
> > > >> the version to zero". So, in the `group.coordinator.version' case,
> we
> > > >> probably should use version 0 for the old consumer protocol.
> > > >>
> > > >> Jun
> > > >>
> > > >> On Thu, Mar 28, 2024 at 2:13 AM Andrew Schofield <
> > > >> andrew_schofield_j...@outlook.com> wrote:
> > > >>
> > > >> > Hi David,
> > > >> > I agree that we should use the same mechanism to gate KIP-932 once
> > > that
> > > >> > feature reaches production readiness. The precise details of the
> > > values
> > > >> > will
> > > >> > depend upon the current state of all these flags when that release
> > > >> comes.
> > > >> >
> > > >> > Thanks,
> > > >> > Andrew
> > > >> >
> > > >> > > On 28 Mar 2024, at 07:11, David Jacot
>  > >
> > > >> > wrote:
> > > >> > >
> > > >> > > Hi, Jun, Justine,
> > > >> > >
> > > >> > > Regarding `group.coordinator.version`, the idea is to use it to
> > gate
> > > >> > > records and APIs of the group coordinator. The first use case
> will
> > > be
> > > >> > > KIP-848. We will use version 2 of the flag to gate all the new
> > > records
> > > >> > and
> > > >> > > the new ConsumerGroupHeartbeat/Describe APIs present in AK 3.8.
> So
> > > >> > version
> > > >> > > 1 will be the only the old protocol and version 2 will be the
> > > >> currently
> > > >> > > implemented new protocol. I don't think that we have any
> > dependency
> > > on
> > > >> > the
> > > >> > > metadata version at the moment. The changes are orthogonal. I
> > think
> > > >> that
> > > >> > we
> > > >> > > could mention KIP-848 as the first usage of this flag in the
> KIP.
> > I
> > > >> will
> > > >> > > also update KIP-848 to include it when this KIP is accepted.
> > Another
> > > >> use
> > > >> > > case is the Queues KIP. I think that we should also use this new
> > > flag
> > > >> to
> > > >> > > gate 

[jira] [Created] (KAFKA-16456) Can't stop kafka debug logs

[Rajan Choudhary (Jira)]

Rajan Choudhary created KAFKA-16456:
---

 Summary: Can't stop kafka debug logs
 Key: KAFKA-16456
 URL: https://issues.apache.org/jira/browse/KAFKA-16456
 Project: Kafka
  Issue Type: Bug
  Components: logging
Affects Versions: 3.6.0
Reporter: Rajan Choudhary


I am getting kafka debug logs, which are flooding our logs. Sample below

 
{code:java}
09:50:38.073 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.NetworkClient - [Producer clientId=maximo-mp, 
transactionalId=sqout-3664816744674374805414] Received API_VERSIONS response 
from node 5 for request with header RequestHeader(apiKey=API_VERSIONS, 
apiVersion=3, clientId=maximo-mp, correlationId=8): 
ApiVersionsResponseData(errorCode=0, apiKeys=[ApiVersion(apiKey=0, 
minVersion=0, maxVersion=9), ApiVersion(apiKey=1, minVersion=0, maxVersion=13), 
ApiVersion(apiKey=2, minVersion=0, maxVersion=7), ApiVersion(apiKey=3, 
minVersion=0, maxVersion=12), ApiVersion(apiKey=4, minVersion=0, maxVersion=5), 
ApiVersion(apiKey=5, minVersion=0, maxVersion=3), ApiVersion(apiKey=6, 
minVersion=0, maxVersion=7), ApiVersion(apiKey=7, minVersion=0, maxVersion=3), 
ApiVersion(apiKey=8, minVersion=0, maxVersion=8), ApiVersion(apiKey=9, 
minVersion=0, maxVersion=8), ApiVersion(apiKey=10, minVersion=0, maxVersion=4), 
ApiVersion(apiKey=11, minVersion=0, maxVersion=7), ApiVersion(apiKey=12, 
minVersion=0, m...

09:50:38.073 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.NetworkClient - [Producer clientId=maximo-mp, 
transactionalId=sqout-3664816744674374805414] Node 5 has finalized features 
epoch: 1, finalized features: [], supported features: [], API versions: 
(Produce(0): 0 to 9 [usable: 9], Fetch(1): 0 to 13 [usable: 12], 
ListOffsets(2): 0 to 7 [usable: 6], Metadata(3): 0 to 12 [usable: 11], 
LeaderAndIsr(4): 0 to 5 [usable: 5], StopReplica(5): 0 to 3 [usable: 3], 
UpdateMetadata(6): 0 to 7 [usable: 7], ControlledShutdown(7): 0 to 3 [usable: 
3], OffsetCommit(8): 0 to 8 [usable: 8], OffsetFetch(9): 0 to 8 [usable: 7], 
FindCoordinator(10): 0 to 4 [usable: 3], JoinGroup(11): 0 to 7 [usable: 7], 
Heartbeat(12): 0 to 4 [usable: 4], LeaveGroup(13): 0 to 4 [usable: 4], 
SyncGroup(14): 0 to 5 [usable: 5], DescribeGroups(15): 0 to 5 [usable: 5], 
ListGroups(16): 0 to 4 [usable: 4], SaslHandshake(17): 0 to 1 [usable: 1], 
ApiVersions(18): 0 to 3 [usable: 3], CreateTopics(19): 0 to 7 [usable: 7], 
Del...

09:50:38.074 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer 
clientId=maximo-mp, transactionalId=sqout-3664816744674374805414] ProducerId of 
partition sqout-0 set to 43458621 with epoch 0. Reinitialize sequence at 
beginning.

09:50:38.074 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.producer.internals.RecordAccumulator - [Producer 
clientId=maximo-mp, transactionalId=sqout-3664816744674374805414] Assigned 
producerId 43458621 and producerEpoch 0 to batch with base sequence 0 being 
sent to partition sqout-0

09:50:38.075 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.NetworkClient - [Producer clientId=maximo-mp, 
transactionalId=sqout-3664816744674374805414] Sending PRODUCE request with 
header RequestHeader(apiKey=PRODUCE, apiVersion=9, clientId=maximo-mp, 
correlationId=9) and timeout 3 to node 5: 
{acks=-1,timeout=3,partitionSizes=[sqout-0=4181]}

09:50:38.095 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.NetworkClient - [Producer clientId=maximo-mp, 
transactionalId=sqout-3664816744674374805414] Received PRODUCE response from 
node 5 for request with header RequestHeader(apiKey=PRODUCE, apiVersion=9, 
clientId=maximo-mp, correlationId=9): 
ProduceResponseData(responses=[TopicProduceResponse(name='sqout', 
partitionResponses=[PartitionProduceResponse(index=0, errorCode=0, 
baseOffset=796494, logAppendTimeMs=-1, logStartOffset=768203, recordErrors=[], 
errorMessage=null)])], throttleTimeMs=0)

09:50:38.095 [kafka-producer-network-thread | maximo-mp] DEBUG 
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer 
clientId=maximo-mp, transactionalId=sqout-3664816744674374805414] ProducerId: 
43458621; Set last ack'd sequence number for topic-partition sqout-0 to 0
09:50:38.147 [pool-7-thread-19] DEBUG 
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer 
clientId=maximo-mp, transactionalId=sqout-3664816744674374805414] Transition 
from state IN_TRANSACTION to COMMITTING_TRANSACTION

09:50:38.147 [pool-7-thread-19] DEBUG 
org.apache.kafka.clients.producer.internals.TransactionManager - [Producer 
clientId=maximo-mp, transactionalId=sqout-3664816744674374805414] Enqueuing 
transactional request 
EndTxnRequestData(transactionalId='sqout-3664816744674374805414', 
producerId=43458621, 

Re: [VOTE] KIP-1020 Move `window.size.ms` and `windowed.inner.serde.class` from `StreamsConfig` to TimeWindowedDe/Serializer class

[Matthias J. Sax]

+1 (binding)


-Matthias

On 4/1/24 7:44 PM, Lucia Cerchie wrote:

Hello everyone,

I'd like to call a vote on KIP-1020
.
It has been under discussion since Feb 15, and has received edits to the
KIP and approval by discussion participants.

Best,
Lucia Cerchie

Jenkins build is unstable: Kafka » Kafka Branch Builder » 3.7 #124

[Apache Jenkins Server]

See