Re: [VOTE] KIP-511: Collect and Expose Client's Name and Version in the Brokers

2019-09-23 Thread David Jacot
Hi Jason, The response will be a flexible version but the response header won't be (only for the api versions response). I have forgotten to change this point in the KIP. I will make this point clearer. I didn't know that INVALID_REQUEST already exists. Yes, it makes sense to reuse it then. Best

Re: [VOTE] KIP-511: Collect and Expose Client's Name and Version in the Brokers

2019-09-23 Thread David Jacot
Hi all, The vote has passed with +3 binding votes (Colin McCabe, Gwen Shapira, Jason Gustafson) and +3 non binding votes (Mickael Maison, Konstantine Karantasis, Kevin Lu). \o/ Thanks to everyone that reviewed and helped improve this proposal, and huge thanks to Colin for his great feedback. Bes

Re: [VOTE] KIP-525 - Return topic metadata and configs in CreateTopics response

2019-09-23 Thread Kamal Chandraprakash
+1 (non-binding), Thanks for the KIP! On Mon, Sep 23, 2019 at 10:45 AM Satish Duggana wrote: > Thanks for the KIP, +1 (non binding) > > This looks to be a useful API for admin tools. When we worked on an > admin tool for Kafka, we had to explicitly call the config API for > showing the configs f

[jira] [Resolved] (KAFKA-8859) Refactor Cache-level Streams Metrics

2019-09-23 Thread Bill Bejeck (Jira)
[ https://issues.apache.org/jira/browse/KAFKA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bejeck resolved KAFKA-8859. Resolution: Fixed > Refactor Cache-level Streams Metrics > > >

[jira] [Resolved] (KAFKA-8086) Flaky Test GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTopicAndGroupRead

2019-09-23 Thread Guozhang Wang (Jira)
[ https://issues.apache.org/jira/browse/KAFKA-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang resolved KAFKA-8086. -- Resolution: Fixed > Flaky Test > GroupAuthorizerIntegrationTest#testPatternSubscriptionWithTop

Re: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible

2019-09-23 Thread Maulin Vasavada
Yes the checks should be mandatory and as I mentioned before we should keep them outside of the pluggable implementation - the way currently it is in SslFactory. I think we can wait for comments from @Colin McCabe and @Rajini Sivaram as soon as they can get some time out of 2.4 release. May be

RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible

2019-09-23 Thread Pellerin, Clement
When I worked on KIP-383 I was told the way to pass extra arguments to an instance is to add extra arguments to configure. I would now suggest we do like the KeySerializer. If you look in KafkaProducer, it creates a KeySerializer using AbstractConfig. getConfiguredInstance(). Since KeySerializer

Re: [DISCUSS] KIP-522: Update BrokerApiVersionsCommand to use AdminClient

2019-09-23 Thread Colin McCabe
Hi Mickael, The brokerApiVersions command was added for administrators, as a debugging tool. It wasn't added so that applications could hard-code version dependencies. Hard-coding different application behaviors in different versions was exactly what we were attempting to avoid. In the examp

Build failed in Jenkins: kafka-trunk-jdk8 #3917

2019-09-23 Thread Apache Jenkins Server
See Changes: [bbejeck] KAFKA-8859: Refactor cache-level metrics (#7367) -- [...truncated 2.64 MB...] org.apache.kafka.streams.scala.kstream.ConsumedTest > Create a Consume

Re: [VOTE] KIP-511: Collect and Expose Client's Name and Version in the Brokers

2019-09-23 Thread Jason Gustafson
Thanks David for the clarification. That sounds good. On Mon, Sep 23, 2019 at 12:35 AM David Jacot wrote: > Hi all, > > The vote has passed with +3 binding votes (Colin McCabe, Gwen Shapira, > Jason Gustafson) and +3 non binding votes (Mickael Maison, Konstantine > Karantasis, Kevin Lu). \o/ > >

Re: [DISCUSS] KIP-527: Add NothingSerde to Serdes

2019-09-23 Thread Nikolay Izhikov
Hello, guys Any additional feeback on this KIP? Should I start a vote? В Пт, 20/09/2019 в 08:52 +0300, Nikolay Izhikov пишет: > Hello, Andrew. > > OK, if nobody mind, let's change it to Null. > > В Чт, 19/09/2019 в 13:54 -0400, Andrew Otto пишет: > > NullSerdes seems more descriptive, but up to

Jenkins build is back to normal : kafka-trunk-jdk11 #828

2019-09-23 Thread Apache Jenkins Server
See

Re: [VOTE] KIP-482: The Kafka Protocol should Support Optional Tagged Fields

2019-09-23 Thread Colin McCabe
On Fri, Sep 20, 2019, at 18:05, Jun Rao wrote: > Hi, Colin, > > Thanks for the KIP. Overall, looks good to me too. A couple of minor > comments. > > 100. Does the tag number need to be 31-bit? It seems that 15-bit could be > enough. I think 15 bit would probably be enough, but there is no extra

Re: [VOTE] KIP-470: TopologyTestDriver test input and output usability improvements

2019-09-23 Thread Jukka Karvanen
Hi All, Thanks for the votes. The vote has passed with 3 binding votes and 2 non-binding. Regards, Jukka pe 20. syysk. 2019 klo 20.19 Patrik Kleindl (pklei...@gmail.com) kirjoitti: > +1 (non-binding) > Thanks for your efforts > Best regards > Patrik > > > Am 20.09.2019 um 19:09 schrieb Bill Be

Re: [DISCUSS] KIP-527: Add NothingSerde to Serdes

2019-09-23 Thread Matthias J. Sax
Because the actually data type is `Void`, I am wondering if `VoidSerde` might be a more descriptive name? -Matthias On 9/23/19 12:25 PM, Nikolay Izhikov wrote: > Hello, guys > > Any additional feeback on this KIP? > Should I start a vote? > > В Пт, 20/09/2019 в 08:52 +0300, Nikolay Izhikov пише

Build failed in Jenkins: kafka-trunk-jdk8 #3918

2019-09-23 Thread Apache Jenkins Server
See Changes: [github] KAFKA-8086: Use 1 partition for offset topic when possible (#7356) [bbejeck] KAFKA-6958: Overload methods for group and windowed stream to allow to

Build failed in Jenkins: kafka-trunk-jdk11 #829

2019-09-23 Thread Apache Jenkins Server
See Changes: [github] KAFKA-8086: Use 1 partition for offset topic when possible (#7356) [bbejeck] KAFKA-6958: Overload methods for group and windowed stream to allow to

Re: [DISCUSS] 2.2.2 Bug Fix Release

2019-09-23 Thread Matthias J. Sax
Just FYI: There was no further feedback about how to handle the regression in 2.2.1 and hence, we consider the proposal accepted, what implies that we can move forward with the 2.2.2 release. -Matthias On 9/13/19 5:23 PM, Randall Hauch wrote: > Thanks, Matthias. I'll get things ready locally bu