Re: [ANNOUNCE] New Kafka PMC member: David Jacot

[Kirk True]

Congrats!

On Fri, Dec 17, 2021, at 8:55 PM, Luke Chen wrote:
> Congrats, David!
> Well deserved.
> 
> Luke
> 
> deng ziming  於 2021年12月18日 週六 上午7:47 寫道：
> 
> > Congrats David!
> >
> > --
> > Ziming Deng
> >
> > > On Dec 18, 2021, at 7:08 AM, Gwen Shapira  wrote:
> > >
> > > Hi everyone,
> > >
> > > David Jacot has been an Apache Kafka committer since Oct 2020 and has
> > been contributing to the community consistently this entire time -
> > especially notable the fact that he reviewed around 150 PRs in the last
> > year. It is my pleasure to announce that David agreed to join the Kafka PMC.
> > >
> > > Congratulations, David!
> > >
> > > Gwen Shapira, on behalf of Apache Kafka PMC
> >
> >
> 

Re: [ANNOUNCE] New Kafka PMC member: David Jacot

[Luke Chen]

Congrats, David!
Well deserved.

Luke

deng ziming  於 2021年12月18日 週六 上午7:47 寫道：

> Congrats David!
>
> --
> Ziming Deng
>
> > On Dec 18, 2021, at 7:08 AM, Gwen Shapira  wrote:
> >
> > Hi everyone,
> >
> > David Jacot has been an Apache Kafka committer since Oct 2020 and has
> been contributing to the community consistently this entire time -
> especially notable the fact that he reviewed around 150 PRs in the last
> year. It is my pleasure to announce that David agreed to join the Kafka PMC.
> >
> > Congratulations, David!
> >
> > Gwen Shapira, on behalf of Apache Kafka PMC
>
>

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

[Apache Jenkins Server]

See 

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.1 #35

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 501833 lines...]
[2021-12-18T01:42:24.803Z] TopicCommandIntegrationTest > 
testCreateWithInvalidReplicationFactor() STARTED
[2021-12-18T01:42:28.451Z] 
[2021-12-18T01:42:28.451Z] TopicCommandIntegrationTest > 
testCreateWithInvalidReplicationFactor() PASSED
[2021-12-18T01:42:28.451Z] 
[2021-12-18T01:42:28.451Z] TopicCommandIntegrationTest > 
testDeleteTopicDoesNotRetryThrottlingQuotaExceededException() STARTED
[2021-12-18T01:42:31.134Z] 
[2021-12-18T01:42:31.134Z] TopicCommandIntegrationTest > 
testDeleteTopicDoesNotRetryThrottlingQuotaExceededException() PASSED
[2021-12-18T01:42:31.134Z] 
[2021-12-18T01:42:31.134Z] TopicCommandIntegrationTest > 
testListTopicsWithExcludeInternal() STARTED
[2021-12-18T01:42:35.713Z] 
[2021-12-18T01:42:35.713Z] TopicCommandIntegrationTest > 
testListTopicsWithExcludeInternal() PASSED
[2021-12-18T01:42:35.713Z] 
[2021-12-18T01:42:35.713Z] TopicCommandIntegrationTest > 
testDescribeUnderReplicatedPartitionsWhenReassignmentIsInProgress() STARTED
[2021-12-18T01:42:39.361Z] 
[2021-12-18T01:42:39.361Z] TopicCommandIntegrationTest > 
testDescribeUnderReplicatedPartitionsWhenReassignmentIsInProgress() PASSED
[2021-12-18T01:42:39.361Z] 
[2021-12-18T01:42:39.361Z] TopicCommandIntegrationTest > 
testCreateWithNegativePartitionCount() STARTED
[2021-12-18T01:42:44.059Z] 
[2021-12-18T01:42:44.059Z] TopicCommandIntegrationTest > 
testCreateWithNegativePartitionCount() PASSED
[2021-12-18T01:42:44.059Z] 
[2021-12-18T01:42:44.059Z] TopicCommandIntegrationTest > 
testAlterWhenTopicDoesntExist() STARTED
[2021-12-18T01:42:46.741Z] 
[2021-12-18T01:42:46.741Z] TopicCommandIntegrationTest > 
testAlterWhenTopicDoesntExist() PASSED
[2021-12-18T01:42:46.741Z] 
[2021-12-18T01:42:46.741Z] TopicCommandIntegrationTest > 
testCreateAlterTopicWithRackAware() STARTED
[2021-12-18T01:42:53.873Z] 
[2021-12-18T01:42:53.873Z] TopicCommandIntegrationTest > 
testCreateAlterTopicWithRackAware() PASSED
[2021-12-18T01:42:53.873Z] 
[2021-12-18T01:42:53.873Z] TopicCommandIntegrationTest > 
testListTopicsWithIncludeList() STARTED
[2021-12-18T01:42:57.523Z] 
[2021-12-18T01:42:57.523Z] TopicCommandIntegrationTest > 
testListTopicsWithIncludeList() PASSED
[2021-12-18T01:42:57.523Z] 
[2021-12-18T01:42:57.523Z] TopicCommandIntegrationTest > testTopicDeletion() 
STARTED
[2021-12-18T01:43:01.173Z] 
[2021-12-18T01:43:01.173Z] TopicCommandIntegrationTest > testTopicDeletion() 
PASSED
[2021-12-18T01:43:01.173Z] 
[2021-12-18T01:43:01.173Z] TopicCommandIntegrationTest > 
testCreateWithDefaults() STARTED
[2021-12-18T01:43:04.823Z] 
[2021-12-18T01:43:04.823Z] TopicCommandIntegrationTest > 
testCreateWithDefaults() PASSED
[2021-12-18T01:43:04.823Z] 
[2021-12-18T01:43:04.823Z] TopicCommandIntegrationTest > 
testDescribeReportOverriddenConfigs() STARTED
[2021-12-18T01:43:08.472Z] 
[2021-12-18T01:43:08.472Z] TopicCommandIntegrationTest > 
testDescribeReportOverriddenConfigs() PASSED
[2021-12-18T01:43:08.472Z] 
[2021-12-18T01:43:08.472Z] TopicCommandIntegrationTest > 
testDescribeWhenTopicDoesntExist() STARTED
[2021-12-18T01:43:12.300Z] 
[2021-12-18T01:43:12.300Z] TopicCommandIntegrationTest > 
testDescribeWhenTopicDoesntExist() PASSED
[2021-12-18T01:43:12.300Z] 
[2021-12-18T01:43:12.300Z] TopicCommandIntegrationTest > 
testDescribeDoesNotFailWhenListingReassignmentIsUnauthorized() STARTED
[2021-12-18T01:43:16.999Z] 
[2021-12-18T01:43:16.999Z] TopicCommandIntegrationTest > 
testDescribeDoesNotFailWhenListingReassignmentIsUnauthorized() PASSED
[2021-12-18T01:43:16.999Z] 
[2021-12-18T01:43:16.999Z] TopicCommandIntegrationTest > 
testAlterAssignmentWithMoreAssignmentThanPartitions() STARTED
[2021-12-18T01:43:19.858Z] 
[2021-12-18T01:43:19.858Z] TopicCommandIntegrationTest > 
testAlterAssignmentWithMoreAssignmentThanPartitions() PASSED
[2021-12-18T01:43:19.858Z] 
[2021-12-18T01:43:19.858Z] TopicCommandIntegrationTest > 
testDescribeWhenTopicDoesntExistWithIfExists() STARTED
[2021-12-18T01:43:23.507Z] 
[2021-12-18T01:43:23.507Z] TopicCommandIntegrationTest > 
testDescribeWhenTopicDoesntExistWithIfExists() PASSED
[2021-12-18T01:43:23.507Z] 
[2021-12-18T01:43:23.507Z] TopicCommandIntegrationTest > 
testCreateWithDefaultPartitions() STARTED
[2021-12-18T01:43:27.158Z] 
[2021-12-18T01:43:27.158Z] TopicCommandIntegrationTest > 
testCreateWithDefaultPartitions() PASSED
[2021-12-18T01:43:27.158Z] 
[2021-12-18T01:43:27.158Z] TopicCommandIntegrationTest > testListTopics() 
STARTED
[2021-12-18T01:43:30.808Z] 
[2021-12-18T01:43:30.808Z] TopicCommandIntegrationTest > testListTopics() PASSED
[2021-12-18T01:43:30.808Z] 
[2021-12-18T01:43:30.808Z] TopicCommandIntegrationTest > 
testDeleteWhenTopicDoesntExistWithIfExists() STARTED
[2021-12-18T01:43:34.458Z] 
[2021-12-18T01:43:34.458Z] TopicCommandIntegrationTest > 
testDeleteWhenTopicDoesntExistWithIfExists() PASSED
[2021-12-18T01:43:34.458Z] 

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

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-13544) Deadlock during shutting down kafka broker because of connectivity problem with zookeeper

[Jun Rao (Jira)]

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

Jun Rao resolved KAFKA-13544.
-
Fix Version/s: 3.2.0
   Resolution: Fixed

Merged the PR to trunk.

> Deadlock during shutting down kafka broker because of connectivity problem 
> with zookeeper 
> --
>
> Key: KAFKA-13544
> URL: https://issues.apache.org/jira/browse/KAFKA-13544
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.8.1
>Reporter: Andrei Lakhmanets
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: kafka_broker_logs.log, kafka_broker_stackdump.txt
>
>
> Hi team,
> *Kafka version:* 2.8.1
> *Configuration:* 3 kafka brokers in different availability zones and 3 
> zookeeper brokers in different availability zones.
> I faced with deadlock in kafka. I've attached stack dump of the kafka state 
> to this ticket. The locked threads are "feature-zk-node-event-process-thread" 
> and "kafka-shutdown-hook".
> *Context:*
> My kafka cluster had connectivity problems with zookeeper and in the logs I 
> saw the next exception:
> The stacktrace:
> {code:java}
> [2021-12-06 18:31:14,629] WARN Unable to reconnect to ZooKeeper service, 
> session 0x1039563000f has expired (org.apache.zookeeper.ClientCnxn)
> [2021-12-06 18:31:14,629] INFO Unable to reconnect to ZooKeeper service, 
> session 0x1039563000f has expired, closing socket connection 
> (org.apache.zookeeper.ClientCnxn)
> [2021-12-06 18:31:14,629] INFO EventThread shut down for session: 
> 0x1039563000f (org.apache.zookeeper.ClientCnxn)
> [2021-12-06 18:31:14,631] INFO [ZooKeeperClient Kafka server] Session 
> expired. (kafka.zookeeper.ZooKeeperClient)
> [2021-12-06 18:31:14,632] ERROR [feature-zk-node-event-process-thread]: 
> Failed to process feature ZK node change event. The broker will eventually 
> exit. 
> (kafka.server.FinalizedFeatureChangeListener$ChangeNotificationProcessorThread)
> kafka.zookeeper.ZooKeeperClientExpiredException: Session expired either 
> before or while waiting for connection
>     at 
> kafka.zookeeper.ZooKeeperClient.waitUntilConnected(ZooKeeperClient.scala:279)
>     at 
> kafka.zookeeper.ZooKeeperClient.$anonfun$waitUntilConnected$1(ZooKeeperClient.scala:261)
>     at 
> kafka.zookeeper.ZooKeeperClient.waitUntilConnected(ZooKeeperClient.scala:261)
>     at 
> kafka.zk.KafkaZkClient.retryRequestsUntilConnected(KafkaZkClient.scala:1797)
>     at 
> kafka.zk.KafkaZkClient.retryRequestsUntilConnected(KafkaZkClient.scala:1767)
>     at 
> kafka.zk.KafkaZkClient.retryRequestUntilConnected(KafkaZkClient.scala:1762)
>     at kafka.zk.KafkaZkClient.getDataAndStat(KafkaZkClient.scala:771)
>     at kafka.zk.KafkaZkClient.getDataAndVersion(KafkaZkClient.scala:755)
>     at 
> kafka.server.FinalizedFeatureChangeListener$FeatureCacheUpdater.updateLatestOrThrow(FinalizedFeatureChangeListener.scala:74)
>     at 
> kafka.server.FinalizedFeatureChangeListener$ChangeNotificationProcessorThread.doWork(FinalizedFeatureChangeListener.scala:147)
>     at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:96) {code}
> The exception is thrown in feature-zk-node-event-process-thread thread and it 
> is catched in method 
> FinalizedFeatureChangeListener.ChangeNotificationProcessorThread.doWork and 
> then doWork method throws FatalExitError(1).
> The FatalExitError catched in ShutdownableThread.run method and call 
> Exit.exit(e.statusCode()) which calls System.exit under the hood.
> The stackdump of "feature-zk-node-event-process-thread" thread:
> {code:java}
> "feature-zk-node-event-process-thread" #23 prio=5 os_prio=0 cpu=163.19ms 
> elapsed=1563046.32s tid=0x7fd0dcdec800 nid=0x2088 in Object.wait()  
> [0x7fd07e2c1000]
>    java.lang.Thread.State: WAITING (on object monitor)
>     at java.lang.Object.wait(java.base@11.0.11/Native Method)
>     - waiting on 
>     at java.lang.Thread.join(java.base@11.0.11/Thread.java:1300)
>     - waiting to re-lock in wait() <0x88b9d3c8> (a 
> org.apache.kafka.common.utils.KafkaThread)
>     at java.lang.Thread.join(java.base@11.0.11/Thread.java:1375)
>     at 
> java.lang.ApplicationShutdownHooks.runHooks(java.base@11.0.11/ApplicationShutdownHooks.java:107)
>     at 
> java.lang.ApplicationShutdownHooks$1.run(java.base@11.0.11/ApplicationShutdownHooks.java:46)
>     at java.lang.Shutdown.runHooks(java.base@11.0.11/Shutdown.java:130)
>     at java.lang.Shutdown.exit(java.base@11.0.11/Shutdown.java:174)
>     - locked <0x806872f8> (a java.lang.Class for java.lang.Shutdown)
>     at java.lang.Runtime.exit(java.base@11.0.11/Runtime.java:116)
>     at java.lang.System.exit(java.base@11.0.11/System.java:1752)
>     at org.apache.kafka.common.utils.Exit$2.execute(Exit.java:43)
>     at 

[jira] [Created] (KAFKA-13555) Consider number if input topic partitions for task assignment

[Matthias J. Sax (Jira)]

Matthias J. Sax created KAFKA-13555:
---

 Summary: Consider number if input topic partitions for task 
assignment
 Key: KAFKA-13555
 URL: https://issues.apache.org/jira/browse/KAFKA-13555
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Reporter: Matthias J. Sax


StreamsAssignor tries to distribute tasks evenly across all instances/threads 
of a Kafka Streams application. It knows about instances/thread (to give more 
capacity to instances with more thread), and it distinguishes between stateless 
and stateful tasks. We also try to not move state around but to use a sticky 
assignment if possible. However, the assignment does not take the number of 
input topic partitions into account.

For example, an upstream tasks could compute two joins, and thus has 3 input 
partitions, while a downstream task compute a follow up aggregation with a 
single input partitions (from the repartition topic). It could happen that one 
thread gets the 3 input partition tasks assigned, while the other thread get 
the single input partition tasks assigned resulting to an uneven partition 
assignment across both threads.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [ANNOUNCE] New Kafka PMC member: David Jacot

[deng ziming]

Congrats David!

--
Ziming Deng

> On Dec 18, 2021, at 7:08 AM, Gwen Shapira  wrote:
> 
> Hi everyone,
> 
> David Jacot has been an Apache Kafka committer since Oct 2020 and has been 
> contributing to the community consistently this entire time - especially 
> notable the fact that he reviewed around 150 PRs in the last year. It is my 
> pleasure to announce that David agreed to join the Kafka PMC.
> 
> Congratulations, David!
> 
> Gwen Shapira, on behalf of Apache Kafka PMC

Re: [ANNOUNCE] New Kafka PMC member: David Jacot

[Bill Bejeck]

Congratulations David! Well deserved.

-Bill

On Fri, Dec 17, 2021 at 6:43 PM José Armando García Sancio
 wrote:

> Congrats David!
>
> On Fri, Dec 17, 2021 at 3:09 PM Gwen Shapira  wrote:
> >
> > Hi everyone,
> >
> > David Jacot has been an Apache Kafka committer since Oct 2020 and has
> been contributing to the community consistently this entire time -
> especially notable the fact that he reviewed around 150 PRs in the last
> year. It is my pleasure to announce that David agreed to join the Kafka PMC.
> >
> > Congratulations, David!
> >
> > Gwen Shapira, on behalf of Apache Kafka PMC
>
>
>
> --
> -Jose
>

Re: [ANNOUNCE] New Kafka PMC member: David Jacot

[José Armando García Sancio]

Congrats David!

On Fri, Dec 17, 2021 at 3:09 PM Gwen Shapira  wrote:
>
> Hi everyone,
>
> David Jacot has been an Apache Kafka committer since Oct 2020 and has been 
> contributing to the community consistently this entire time - especially 
> notable the fact that he reviewed around 150 PRs in the last year. It is my 
> pleasure to announce that David agreed to join the Kafka PMC.
>
> Congratulations, David!
>
> Gwen Shapira, on behalf of Apache Kafka PMC



-- 
-Jose

Re: [DISCUSS] Apache Kafka 3.1.0 release

[José Armando García Sancio]

Hi David Jacot,

I cherry picked this commit https://github.com/apache/kafka/pull/11511
to the 3.1 branch to fix the kafka.metrics.MetricsTest integration
tests for that branch.

Thanks,
-Jose

On Tue, Dec 14, 2021 at 8:09 AM David Jacot  wrote:
>
> Hi Jason,
>
> Thanks for bringing this up. I do agree with you that it makes sense
> to include this follow up to correctly fix the entire issue in 3.1.
>
> Thanks,
> David
>
> On Mon, Dec 13, 2021 at 9:01 PM Jason Gustafson
>  wrote:
> >
> > Hi David,
> >
> > I think we should get https://issues.apache.org/jira/browse/KAFKA-13488.
> > This is a follow-up to https://issues.apache.org/jira/browse/KAFKA-12257,
> > which was previously considered a 3.0 blocker. Without the additional
> > patch, the bug causing the consumer to get stuck can still occur in a
> > common scenario.
> >
> > Thanks,
> > Jason
> >
> > On Tue, Dec 7, 2021 at 11:19 PM David Jacot 
> > wrote:
> >
> > > Hi Justine,
> > >
> > > I am +1 on getting this in the 3.1 release as it is a serious
> > > regression in clusters with a high number of partitions.
> > >
> > > Thanks,
> > > David
> > >
> > > On Tue, Dec 7, 2021 at 10:39 PM Justine Olshan
> > >  wrote:
> > > >
> > > > Hi all,
> > > > I've filed a bug for an extra map allocation that is used in the fetch
> > > > path. https://issues.apache.org/jira/browse/KAFKA-13512
> > > > I think it qualifies as a blocker since this path is used pretty
> > > frequently
> > > > and it looks to be a regression.
> > > >
> > > > I also have a PR open to fix the issue. With this change, the 
> > > > performance
> > > > looks much better. https://github.com/apache/kafka/pull/11576
> > > > Thanks,
> > > > Justine
> > > >
> > > > On Fri, Dec 3, 2021 at 5:29 AM David Jacot 
> > > > wrote:
> > > >
> > > > > Hi Rajini,
> > > > >
> > > > > Interesting bug. The patch seems to be low risk so I suppose that
> > > > > it is fine to keep it in 3.1.0.
> > > > >
> > > > > Thanks,
> > > > > David
> > > > >
> > > > > On Fri, Dec 3, 2021 at 2:26 PM David Jacot 
> > > wrote:
> > > > > >
> > > > > > Hi Colin,
> > > > > >
> > > > > > Thanks for the heads up. It makes sense to include it in order
> > > > > > to keep the KRaft inline with ZK behavior.
> > > > > >
> > > > > > Thanks,
> > > > > > David
> > > > > >
> > > > > > On Fri, Dec 3, 2021 at 9:44 AM Rajini Sivaram <
> > > rajinisiva...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Hi David,
> > > > > > >
> > > > > > > Sorry, I had completely forgotten about code freeze and merged
> > > > > > > https://issues.apache.org/jira/browse/KAFKA-13461 to 3.1 branch
> > > > > yesterday.
> > > > > > > Can you take a look and see if we want it in 3.1.0? It is not a
> > > > > regression
> > > > > > > in 3.1, but we see this issue in tests and when it happens, the
> > > > > controller
> > > > > > > no longer operates as a controller.
> > > > > > >
> > > > > > > Thank you,
> > > > > > >
> > > > > > > Rajini
> > > > > > >
> > > > > > > On Thu, Dec 2, 2021 at 10:56 PM Colin McCabe 
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi David,
> > > > > > > >
> > > > > > > > We'd like to include "KAFKA-13490: Fix createTopics and
> > > > > > > > incrementalAlterConfigs for KRaft mode #11416" in the upcoming
> > > > > release.
> > > > > > > > This fixes some bugs in how createTopics and
> > > incrementalAlterConfigs
> > > > > are
> > > > > > > > handled by the controller. It is specific to KRaft, so will not
> > > > > affect ZK
> > > > > > > > mode.
> > > > > > > >
> > > > > > > > best,
> > > > > > > > Colin
> > > > > > > >
> > > > > > > > On Wed, Nov 24, 2021, at 01:20, David Jacot wrote:
> > > > > > > > > Hi Mickael,
> > > > > > > > >
> > > > > > > > > Thanks for reporting it. It makes sense to include it in the
> > > 3.1
> > > > > release
> > > > > > > > > as well as it is a regression.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > David
> > > > > > > > >
> > > > > > > > > On Tue, Nov 23, 2021 at 6:52 PM Mickael Maison <
> > > > > mickael.mai...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> Hi David,
> > > > > > > > >>
> > > > > > > > >> Can we also consider
> > > > > https://issues.apache.org/jira/browse/KAFKA-13397?
> > > > > > > > >> It's essentially a regression but in a very specific case. To
> > > hit
> > > > > it,
> > > > > > > > >> you must be running MirrorMaker in dedicated mode and have
> > > > > changed the
> > > > > > > > >> separator of the default replication policy.
> > > > > > > > >>
> > > > > > > > >> Thanks,
> > > > > > > > >> Mickael
> > > > > > > > >>
> > > > > > > > >> On Tue, Nov 23, 2021 at 4:58 PM David Jacot
> > > > > 
> > > > > > > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > Hi Ron,
> > > > > > > > >> >
> > > > > > > > >> > Thank you for reaching out about this. While this is 
> > > > > > > > >> > clearly
> > > > > not a
> > > > > > > > >> > regression, I agree with including it in 3.1 in order to
> > > have
> > > > > proper
> > > > > > > > >> > and correct 

[jira] [Created] (KAFKA-13554) Rename RangeQuery to KeyRangeQuery

[John Roesler (Jira)]

John Roesler created KAFKA-13554:


 Summary: Rename RangeQuery to KeyRangeQuery
 Key: KAFKA-13554
 URL: https://issues.apache.org/jira/browse/KAFKA-13554
 Project: Kafka
  Issue Type: Sub-task
Reporter: John Roesler


Just to avoid confusion wrt WindowRangeQuery



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (KAFKA-13553) Add DSL stores to IQv2StoreIntegrationTest

[John Roesler (Jira)]

John Roesler created KAFKA-13553:


 Summary: Add DSL stores to IQv2StoreIntegrationTest
 Key: KAFKA-13553
 URL: https://issues.apache.org/jira/browse/KAFKA-13553
 Project: Kafka
  Issue Type: Sub-task
Reporter: John Roesler


Right now, we only test stores registered via the DSL. To be truly 
comprehensive, we must also test stores registered via the PAPI.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[ANNOUNCE] New Kafka PMC member: David Jacot

[Gwen Shapira]

Hi everyone,

David Jacot has been an Apache Kafka committer since Oct 2020 and has been 
contributing to the community consistently this entire time - especially 
notable the fact that he reviewed around 150 PRs in the last year. It is my 
pleasure to announce that David agreed to join the Kafka PMC.

Congratulations, David!

Gwen Shapira, on behalf of Apache Kafka PMC

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #586

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-778 KRaft upgrades

[David Arthur]

The vote has passed with the following results:

4 binding votes from: Guozhang, José, Colin, and Jun
2 non-binding votes from: Ziming Deng and Kowshik
no -1 votes

Thanks to everyone for all the thoughtful feedback for this KIP.
Much appreciated!

-David

On Fri, Dec 17, 2021 at 12:36 PM Jun Rao  wrote:

> Thanks, David. +1 from me.
>
> Jun
>
> On Fri, Dec 17, 2021 at 7:59 AM David Arthur
>  wrote:
>
> > Yes we'll need to bump ApiVersions request/response version to 4. I have
> a
> > small note in the Public Interfaces that we'll drop MinVersionLevel in
> > ApiVersionsResponse version 4.
> >
> > I believe we can avoid bumping the version of FeatureLevelRecord since
> > KRaft doesn't support the UpgradeFeatures RPC (and so can't have written
> > any FeatureLevelRecord).
> >
> > On Thu, Dec 16, 2021 at 2:48 PM Jun Rao 
> wrote:
> >
> > > Hi, David,
> > >
> > > Thanks for the KIP. It seems that we removed MinVersionLevel from ZK
> > > and FeatureLevelRecord in the latest change. Should we
> > > remove MinVersionLevel from ApiVersionsResponse too? Should we bump up
> > the
> > > version in FeatureLevelRecord and ApiVersionsRequest?
> > >
> > > Jun
> > >
> > > On Thu, Dec 16, 2021 at 10:14 AM Colin McCabe 
> > wrote:
> > >
> > > > Thanks for the KIP, David! Great work.
> > > >
> > > > +1 (binding).
> > > >
> > > > Should the "./kafka-features.sh downgrade" command also have a
> > --release
> > > > flag, to match upgrade?
> > > >
> > > > Also, it seems like upgrade should have a --latest flag that upgrades
> > > > everything to the latest installed version?
> > > >
> > > > best,
> > > > Colin
> > > >
> > > >
> > > > On Fri, Dec 10, 2021, at 12:49, David Arthur wrote:
> > > > > Hey everyone, I'd like to start a vote for KIP-778 which adds
> support
> > > for
> > > > > KRaft to KRaft upgrades.
> > > > >
> > > > > Notably in this KIP is the first use case of KIP-584 feature flags.
> > As
> > > > > such, there are some addendums to KIP-584 included.
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-778%3A+KRaft+Upgrades
> > > > >
> > > > > Thanks!
> > > > > David
> > > >
> > >
> >
> >
> > --
> > -David
> >
>

Re: [VOTE] KIP-778 KRaft upgrades

[Jun Rao]

Thanks, David. +1 from me.

Jun

On Fri, Dec 17, 2021 at 7:59 AM David Arthur
 wrote:

> Yes we'll need to bump ApiVersions request/response version to 4. I have a
> small note in the Public Interfaces that we'll drop MinVersionLevel in
> ApiVersionsResponse version 4.
>
> I believe we can avoid bumping the version of FeatureLevelRecord since
> KRaft doesn't support the UpgradeFeatures RPC (and so can't have written
> any FeatureLevelRecord).
>
> On Thu, Dec 16, 2021 at 2:48 PM Jun Rao  wrote:
>
> > Hi, David,
> >
> > Thanks for the KIP. It seems that we removed MinVersionLevel from ZK
> > and FeatureLevelRecord in the latest change. Should we
> > remove MinVersionLevel from ApiVersionsResponse too? Should we bump up
> the
> > version in FeatureLevelRecord and ApiVersionsRequest?
> >
> > Jun
> >
> > On Thu, Dec 16, 2021 at 10:14 AM Colin McCabe 
> wrote:
> >
> > > Thanks for the KIP, David! Great work.
> > >
> > > +1 (binding).
> > >
> > > Should the "./kafka-features.sh downgrade" command also have a
> --release
> > > flag, to match upgrade?
> > >
> > > Also, it seems like upgrade should have a --latest flag that upgrades
> > > everything to the latest installed version?
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Fri, Dec 10, 2021, at 12:49, David Arthur wrote:
> > > > Hey everyone, I'd like to start a vote for KIP-778 which adds support
> > for
> > > > KRaft to KRaft upgrades.
> > > >
> > > > Notably in this KIP is the first use case of KIP-584 feature flags.
> As
> > > > such, there are some addendums to KIP-584 included.
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-778%3A+KRaft+Upgrades
> > > >
> > > > Thanks!
> > > > David
> > >
> >
>
>
> --
> -David
>

Re: [DISCUSS] KIP-778 KRaft Upgrades

[David Arthur]

Tom, thanks for taking a look!

1. Yes you're right, I'll fix that
2. Components refers to broker objects like ReplicaManager,
ClientQuotaManager, etc. Controller components (so far) don't need to
reload any state based on metadata.version changes.
3. Yes, if a controller reads a FeatureLevelRecord from a snapshot or
commit event, and it's for an unsupportable metadata.version, it will
terminate
4. I think it should be impossible for the active controller to read an
unsupported metadata.version except for bugs
5. Yes that's possible, however once B sees the new version, it will close
its connections to A and force the ApiVersions exchange to happen again.
This is an area we're looking to improve on in a future KIP
6. Yes, it should, I'll add.

Cheers,
David

On Fri, Dec 17, 2021 at 12:16 PM Tom Bentley  wrote:

> Hi David,
>
> Thanks for the KIP. Sorry I'm so late in looking at this. I have a few
> questions.
>
> 1. In the Proposed Changes Overview it says "The controller validates that
> the cluster can be safely downgraded to this version (override with
> --force)" I think that be "--unsafe"?
>
> 2. Also in this section it says "Components reload their state with new
> version" the word "components" is a little vague. I think it means
> controllers and brokers, right?
>
> 3. In the compatibility section it says "A controller running old software
> will join the quorum and begin replicating the metadata log. If this
> inactive controller encounters a FeatureLevelRecord for *metadata.version*
> that it cannot support, it should terminate." I assume "encounters"
> includes the snapshot case?
>
> 4. "In the unlikely event that an active controller encounters an
> unsupported *metadata.version*, it should resign and terminate. ", I'm
> unclear on how this could happen, could you elaborate?
>
> 5. In the ApiVersions part of the Upgrades section, "Brokers will observe
> changes to *metadata.version *as they replicate records from the metadata
> log. If a new *metadata.version* is seen, brokers will renegotiate
> compatible RPCs with other brokers through the the ApiVersions workflow."
> Is it possible that broker A does a metadata fetch, sees a changed
> metadata.version and attempts renegotiation with broker B before B has seen
> the metadata.version?
>
> 6. Why does "kafka-features.sh downgrade" not support "--release"?
>
> Kind regards,
>
> Tom
>
> On Tue, Nov 30, 2021 at 10:26 PM Jun Rao  wrote:
>
> > Hi, David,
> >
> > Thanks for the reply. No more questions from me.
> >
> > Jun
> >
> > On Tue, Nov 30, 2021 at 1:52 PM David Arthur
> >  wrote:
> >
> > > Thanks Jun,
> > >
> > > 30: I clarified the description of the "upgrade" command to:
> > >
> > > The FEATURE and VERSION arguments can be repeated to indicate an
> upgrade
> > of
> > > > multiple features in one request. Alternatively, the RELEASE flag can
> > be
> > > > given to upgrade to the default versions of the specified release.
> > These
> > > > two options, FEATURE and RELEASE, are mutually exclusive. If neither
> is
> > > > given, this command will do nothing.
> > >
> > >
> > > Basically, you must provide either "kafka-features.sh upgrade --release
> > > 3.2" or something like "kafka-features.sh upgrade --feature X --version
> > 10"
> > >
> > > -David
> > >
> > > On Tue, Nov 30, 2021 at 2:51 PM Jun Rao 
> > wrote:
> > >
> > > > Hi, David,
> > > >
> > > > Thanks for the reply. Just one more minor comment.
> > > >
> > > > 30. ./kafka-features.sh upgrade: It seems that the release param is
> > > > optional. Could you describe the semantic when release is not
> > specified?
> > > >
> > > > Jun
> > > >
> > > > On Mon, Nov 29, 2021 at 5:06 PM David Arthur
> > > >  wrote:
> > > >
> > > > > Jun, I updated the KIP with the "disable" CLI.
> > > > >
> > > > > For 16, I think you're asking how we can safely introduce the
> > > > > initial version of other feature flags in the future. This will
> > > probably
> > > > > depend on the nature of the feature that the new flag is gating. We
> > can
> > > > > probably take a similar approach and say version 1 is backwards
> > > > compatible
> > > > > to some point (possibly an IBP or metadata.version?).
> > > > >
> > > > > -David
> > > > >
> > > > > On Fri, Nov 19, 2021 at 3:00 PM Jun Rao 
> > > > wrote:
> > > > >
> > > > > > Hi, David,
> > > > > >
> > > > > > Thanks for the reply. The new CLI sounds reasonable to me.
> > > > > >
> > > > > > 16.
> > > > > > For case C, choosing the latest version sounds good to me.
> > > > > > For case B, for metadata.version, we pick version 1 since it just
> > > > happens
> > > > > > that for metadata.version version 1 is backward compatible. How
> do
> > we
> > > > > make
> > > > > > this more general for other features?
> > > > > >
> > > > > > 21. Do you still plan to change "delete" to "disable" in the CLI?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jun
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Nov 18, 2021 at 11:50 AM David Arthur
> > > > > >  

Re: [DISCUSS] KIP-778 KRaft Upgrades

[Tom Bentley]

Hi David,

Thanks for the KIP. Sorry I'm so late in looking at this. I have a few
questions.

1. In the Proposed Changes Overview it says "The controller validates that
the cluster can be safely downgraded to this version (override with
--force)" I think that be "--unsafe"?

2. Also in this section it says "Components reload their state with new
version" the word "components" is a little vague. I think it means
controllers and brokers, right?

3. In the compatibility section it says "A controller running old software
will join the quorum and begin replicating the metadata log. If this
inactive controller encounters a FeatureLevelRecord for *metadata.version*
that it cannot support, it should terminate." I assume "encounters"
includes the snapshot case?

4. "In the unlikely event that an active controller encounters an
unsupported *metadata.version*, it should resign and terminate. ", I'm
unclear on how this could happen, could you elaborate?

5. In the ApiVersions part of the Upgrades section, "Brokers will observe
changes to *metadata.version *as they replicate records from the metadata
log. If a new *metadata.version* is seen, brokers will renegotiate
compatible RPCs with other brokers through the the ApiVersions workflow."
Is it possible that broker A does a metadata fetch, sees a changed
metadata.version and attempts renegotiation with broker B before B has seen
the metadata.version?

6. Why does "kafka-features.sh downgrade" not support "--release"?

Kind regards,

Tom

On Tue, Nov 30, 2021 at 10:26 PM Jun Rao  wrote:

> Hi, David,
>
> Thanks for the reply. No more questions from me.
>
> Jun
>
> On Tue, Nov 30, 2021 at 1:52 PM David Arthur
>  wrote:
>
> > Thanks Jun,
> >
> > 30: I clarified the description of the "upgrade" command to:
> >
> > The FEATURE and VERSION arguments can be repeated to indicate an upgrade
> of
> > > multiple features in one request. Alternatively, the RELEASE flag can
> be
> > > given to upgrade to the default versions of the specified release.
> These
> > > two options, FEATURE and RELEASE, are mutually exclusive. If neither is
> > > given, this command will do nothing.
> >
> >
> > Basically, you must provide either "kafka-features.sh upgrade --release
> > 3.2" or something like "kafka-features.sh upgrade --feature X --version
> 10"
> >
> > -David
> >
> > On Tue, Nov 30, 2021 at 2:51 PM Jun Rao 
> wrote:
> >
> > > Hi, David,
> > >
> > > Thanks for the reply. Just one more minor comment.
> > >
> > > 30. ./kafka-features.sh upgrade: It seems that the release param is
> > > optional. Could you describe the semantic when release is not
> specified?
> > >
> > > Jun
> > >
> > > On Mon, Nov 29, 2021 at 5:06 PM David Arthur
> > >  wrote:
> > >
> > > > Jun, I updated the KIP with the "disable" CLI.
> > > >
> > > > For 16, I think you're asking how we can safely introduce the
> > > > initial version of other feature flags in the future. This will
> > probably
> > > > depend on the nature of the feature that the new flag is gating. We
> can
> > > > probably take a similar approach and say version 1 is backwards
> > > compatible
> > > > to some point (possibly an IBP or metadata.version?).
> > > >
> > > > -David
> > > >
> > > > On Fri, Nov 19, 2021 at 3:00 PM Jun Rao 
> > > wrote:
> > > >
> > > > > Hi, David,
> > > > >
> > > > > Thanks for the reply. The new CLI sounds reasonable to me.
> > > > >
> > > > > 16.
> > > > > For case C, choosing the latest version sounds good to me.
> > > > > For case B, for metadata.version, we pick version 1 since it just
> > > happens
> > > > > that for metadata.version version 1 is backward compatible. How do
> we
> > > > make
> > > > > this more general for other features?
> > > > >
> > > > > 21. Do you still plan to change "delete" to "disable" in the CLI?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jun
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Nov 18, 2021 at 11:50 AM David Arthur
> > > > >  wrote:
> > > > >
> > > > > > Jun,
> > > > > >
> > > > > > The KIP has some changes to the CLI for KIP-584. With Jason's
> > > > suggestion
> > > > > > incorporated, these three commands would look like:
> > > > > >
> > > > > > 1) kafka-features.sh upgrade --release latest
> > > > > > upgrades all known features to their defaults in the latest
> release
> > > > > >
> > > > > > 2) kafka-features.sh downgrade --release 3.x
> > > > > > downgrade all known features to the default versions from 3.x
> > > > > >
> > > > > > 3) kafka-features.sh describe --release latest
> > > > > > Describe the known features of the latest release
> > > > > >
> > > > > > The --upgrade-all and --downgrade-all are replaced by specific
> each
> > > > > > feature+version or giving the --release argument. One problem
> with
> > > > > > --downgrade-all is it's not clear what the target versions should
> > be:
> > > > the
> > > > > > previous version before the last upgrade -- or the lowest
> supported
> > > > > > version. Since downgrades will be less common, I think it's
> better
> 

Re: [VOTE] KIP-778 KRaft upgrades

[David Arthur]

Yes we'll need to bump ApiVersions request/response version to 4. I have a
small note in the Public Interfaces that we'll drop MinVersionLevel in
ApiVersionsResponse version 4.

I believe we can avoid bumping the version of FeatureLevelRecord since
KRaft doesn't support the UpgradeFeatures RPC (and so can't have written
any FeatureLevelRecord).

On Thu, Dec 16, 2021 at 2:48 PM Jun Rao  wrote:

> Hi, David,
>
> Thanks for the KIP. It seems that we removed MinVersionLevel from ZK
> and FeatureLevelRecord in the latest change. Should we
> remove MinVersionLevel from ApiVersionsResponse too? Should we bump up the
> version in FeatureLevelRecord and ApiVersionsRequest?
>
> Jun
>
> On Thu, Dec 16, 2021 at 10:14 AM Colin McCabe  wrote:
>
> > Thanks for the KIP, David! Great work.
> >
> > +1 (binding).
> >
> > Should the "./kafka-features.sh downgrade" command also have a --release
> > flag, to match upgrade?
> >
> > Also, it seems like upgrade should have a --latest flag that upgrades
> > everything to the latest installed version?
> >
> > best,
> > Colin
> >
> >
> > On Fri, Dec 10, 2021, at 12:49, David Arthur wrote:
> > > Hey everyone, I'd like to start a vote for KIP-778 which adds support
> for
> > > KRaft to KRaft upgrades.
> > >
> > > Notably in this KIP is the first use case of KIP-584 feature flags. As
> > > such, there are some addendums to KIP-584 included.
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-778%3A+KRaft+Upgrades
> > >
> > > Thanks!
> > > David
> >
>


-- 
-David

Re: [VOTE] KIP-806: Add session and window query over KV-store in IQv2

[Patrick Stuedi]

Thanks everyone for voting.

Voting passed with the following +1s:

- Luke Chen
- Guozhang Wang (binding)
- John Roesler (binding)
- Bruno Cadonna (binding)

I'll update the KIP status accordingly.

Best,
  Patrick

On Thu, Dec 16, 2021 at 2:09 PM Bruno Cadonna  wrote:

> Hi Partick,
>
> Thank you for the KIP!
>
> +1 (binding)
>
> Best,
> Bruno
>
> On 16.12.21 07:22, Luke Chen wrote:
> > Hi Patrick, John,
> >
> > Thanks for your explanation and update.
> > It looks better now.
> >
> > +1 (non-binding) from me.
> >
> > just one minor comment:
> > 10. In the example section, we are still using the variable names `lower`
> > and `upper` as before. We should update them, too. (follow the decision
> for
> > point 7 above)
> >
> > Thank you.
> > Luke
> >
> > On Thu, Dec 16, 2021 at 3:34 AM Guozhang Wang 
> wrote:
> >
> >> Thanks Patrick, John.
> >>
> >> I read through the updated KIP and it's much cleared on the scope now,
> >> appreciate that! I'm +1 overall, modulo a few minor comments:
> >>
> >> 7. The parameter names of `WindowKeyQuery#withKeyAndWindowStartRange`,
> i.e.
> >> `startTime` and `endTime` seem not updated; also for the parameter
> names of
> >> `WindowRangeQuery#withWindowStartRange`, the `earliest / latest` seems
> >> inconsistent with the existing API parameter names, how about naming
> both
> >> of them `fromWindowStartTime` and `toWindowStartTime`?
> >>
> >> 8.  `getStartTime / getEndTime` are not updated as well: should they be
> >> `getEarliestWindowStartTime` / `getLatestWindowStartTime` or `getFrom...
> >> getTo...` if you agree with 7) above?
> >>
> >> 9. "One reason we cannot use WindowKeyQuery to support
> >> SessionStore.fetch(key)": not sure I understand this part, for the new
> APIs
> >> we do not need to be following the old API's return types since they are
> >> separated, right? So if we think it's actually better for the new API
> >> mimicing `sessionStore.fetch(key)` to return a `WindowStoreIterator`,
> >> why can't we just do that?
> >>
> >>
> >> Guozhang
> >>
> >> On Wed, Dec 15, 2021 at 8:49 AM John Roesler 
> wrote:
> >>
> >>> FYI, I filed this follow-on task to explore a more general
> >>> pattern for these queries:
> >>> https://issues.apache.org/jira/browse/KAFKA-13548
> >>>
> >>> We can unblock the current scope for these queries but still
> >>> plan to revisit the API before the first release of IQv2.
> >>>
> >>> Thanks!
> >>> -John
> >>>
> >>> On Wed, 2021-12-15 at 10:34 -0600, John Roesler wrote:
>  Thanks for the update, Patrick!
> 
>  Tl;dr: I'm +1 (binding)
> 
>  I just reviewed the KIP again (I hope you don't mind, I
>  fixed a couple of missed renames in the text and examples).
> 
>  One of the design of IQv2 is to make proposing and evolving
>  these queries much less onerous. Unlike adding new methods
>  to all StateStore interfaces and implementations, if we want
>  to make (eg) the WindowRangeQuery more flexible in the
>  future, we can easily do so by just adding some builder
>  methods to set the bounds independently, or by adding new
>  static methods to provide different parameterizations.
> 
>  Therefore, even though this is not the ultimate expression
>  of what we think the range queries should be, it's a
>  perfectly fine starting point. The most pressing concerns to
>  me were the cases where Luke and Guozhang pointed out that
>  some parts of the proposal or interfaces were ambiguous,
>  which looks like it's fixed now.
> 
>  My preference would be to go ahead and accept this proposed
>  scope so that we have at least some basic key-value, window,
>  and session store queries in the code base. Until we have
>  those MVP queries in place, we can't really start to address
>  higher-level follow-up items like:
>  https://issues.apache.org/jira/browse/KAFKA-13541 (to refine
>  how the serdes interplay with the queries) or
>  https://issues.apache.org/jira/browse/KAFKA-13541 (to
>  consider alternative ways to pin down the generic type
>  parameters better).
> 
>  Anyway, for the current version of the KIP, my vote is +1
>  (binding).
> 
>  Thanks again!
>  -John
> 
>  On Wed, 2021-12-15 at 12:53 +0100, Patrick Stuedi wrote:
> > Thanks everyone for the sharing comments and suggestions, this is
> > very helpful!
> >
> > I have updated the KIP based on the suggestions, please let me know
> >>> what
> > you think. Here are the main changes:
> > - Removed constructor in WindowRangeQuery (Guozhang)
> > - Clearly specified how each of the instantiation of the different
> >>> query
> > types maps to specific operations in WindowStore and SessionStore
> >>> (Guozhang)
> > - Renamed the window start end time parameters and getter methods
> >>> (Luke)
> > - Added some comments on the use of WindowRangeQuery.fromKey
> >> (Guozhang,
> > John)
> >
> > The 

Understanding the SASL/PLAIN mechanism

[Jeremy Whitlock]

Hello Kafka Dev,
I realize that this question might be more SASL than Kafka related, but
after endless Googling and code browsing, I'm not understanding a few
things.  I've looked at all of the code for SASL/PLAIN and SASL/OAUTHBEARER
but when attempting to implement my own custom SASL mechanism, there are
gaps in my understanding and I'm really trying to make sure I
understand things before just copying/pasting/refactoring and hoping for
the best.

Does someone have a little time to explain the execution path for
SASL/PLAIN so that I can eventually implement my own custom mechanism?
Here are a few questions I had after spending a good bit of time trying to
figure this out on my own:

1. What runs where?  (Where is the LoginModule run, where are the callbacks
ran, how are SaslClient/SaslServer used, ...)

2. A follow-up to #1 is that the SASL/PLAIN implementation doesn't seem to
have a custom SaslClient implementation but does have a custom SaslServer
implementation.  Why isn't a SaslClient required for SASL/PLAIN?

3. Are callbacks required for anything more than pluggability?  I ask
because for PlainLoginModule, JAAS states that the LoginModule should
perform authentication in login() but PlainLoginModule doesn't do anything
of the sort, just adding details to the Subject.  SaslChannelBuilder wires
up a PlainServerCallbackHandler to do the real work but if pluggability
isn't required, couldn't login() do it?

I think that's it for now.  Ultimately, I want to create my own SASL
mechanism that works in Kafka to do external authentication using more than
just username and password.

Take care,

Jeremy

Re: [DISCUSS] Please review the 3.1.0 blog post

[David Jacot]

Hi Tom,

Thanks for your inputs. I have updated the blog post.

Best,
David

On Thu, Dec 16, 2021 at 3:07 PM Tom Bentley  wrote:
>
> Hi David,
>
> A couple of minor nits:
>
> For KIP-783: "This field is set for any exception that originates from, or
> tied to, a specific task." should be "This field is set for any exception
> that originates from, or *is* tied to, a specific task."
>
> For KIP-690: "...so MM2 should have flexibility to let you override the
> name of internal topics to follow the one you create." could be worded a
> little better, I think "... to *use* the one*s* you create."
>
> Apart from that LGTM.
>
> Thanks!
>
> Tom
>
> On Thu, Dec 16, 2021 at 8:42 AM David Jacot 
> wrote:
>
> > Hey folks,
> >
> > I have updated the blog post based on offline feedback that I have
> > received. The
> > changes were minor.
> >
> > Cheers,
> > David
> >
> > On Wed, Dec 15, 2021 at 3:00 PM Igor Soarez  wrote:
> > >
> > > Hi David,
> > >
> > > Apart from the obviously identified TODO items I coudln't find any
> > issues. It looks great!
> > >
> > > --
> > > Igor
> > >
> > > On Wed, Dec 15, 2021, at 8:37 AM, David Jacot wrote:
> > > > Thanks, Mickael. I will fix this.
> > > >
> > > > Best,
> > > > David
> > > >
> > > > On Mon, Dec 13, 2021 at 3:55 PM Mickael Maison <
> > mickael.mai...@gmail.com> wrote:
> > > >>
> > > >> Hi David,
> > > >>
> > > >> It looks good, I just noticed a typo:
> > > >> "KIP-733" should be "KIP-773"
> > > >>
> > > >> Thanks
> > > >>
> > > >> On Sun, Dec 12, 2021 at 4:05 PM David Jacot
> >  wrote:
> > > >> >
> > > >> > Hi Luke,
> > > >> >
> > > >> > Thanks for your feedback. I have found and have fixed the issue. It
> > was
> > > >> > actually
> > > >> > due to the formatting of the title of the AK 3.0 blog post.
> > > >> >
> > > >> > Best,
> > > >> > David
> > > >> >
> > > >> > On Sat, Dec 11, 2021 at 9:44 AM Luke Chen 
> > wrote:
> > > >> >
> > > >> > > Oh, sorry! I have a typo in your name!
> > > >> > > Sorry, David! >.<
> > > >> > >
> > > >> > > Luke
> > > >> > >
> > > >> > > On Sat, Dec 11, 2021 at 4:42 PM Luke Chen 
> > wrote:
> > > >> > >
> > > >> > >> Hi Davie,
> > > >> > >>
> > > >> > >> Thanks for drafting the release announcement post.
> > > >> > >> I've checked the content, and looks good to me.
> > > >> > >> But I think the header section: "What's New in Apache..." is not
> > > >> > >> formatted properly.
> > > >> > >> I checked the previous blog post, and it should be a hyperlink
> > just like
> > > >> > >> the "Main" kind of font.
> > > >> > >>
> > > >> > >> [image: image.png]
> > > >> > >>
> > > >> > >> Thank you.
> > > >> > >> Luke
> > > >> > >>
> > > >> > >>
> > > >> > >> On Sat, Dec 11, 2021 at 5:51 AM David Jacot
> > 
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >>> I have put the wrong link in my previous email. Here is the
> > public one:
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > https://blogs.apache.org/preview/kafka/?previewEntry=what-s-new-in-apache7
> > > >> > >>>
> > > >> > >>> Best,
> > > >> > >>> David
> > > >> > >>>
> > > >> > >>> On Fri, Dec 10, 2021 at 10:35 PM David Jacot <
> > dja...@confluent.io>
> > > >> > >>> wrote:
> > > >> > >>> >
> > > >> > >>> > Hello all,
> > > >> > >>> >
> > > >> > >>> > I have prepared a draft of the release announcement post for
> > the
> > > >> > >>> > Apache Kafka 3.1.0 release:
> > > >> > >>> >
> > > >> > >>> >
> > > >> > >>>
> > https://blogs.apache.org/roller-ui/authoring/preview/kafka/?previewEntry=what-s-new-in-apache7
> > > >> > >>> >
> > > >> > >>> > I would greatly appreciate your reviews if you have a moment.
> > > >> > >>> >
> > > >> > >>> > Thanks,
> > > >> > >>> > David
> > > >> > >>>
> > > >> > >>
> >
> >