Hi Chia-Ping and Jun, I have updated KIP, thanks.
new link: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1220%3A+Unify+kafka-broker-api-versions+tool+to+cluster-tool+and+support+bootstrap+controllers Best, TaiJuWu Jun Rao via dev <[email protected]> 於 2026年5月6日週三 上午1:38寫道： > Hi, Chia-Ping, > > Migrating the functionality to kafka-cluster.sh looks reasonable to me. > > Thanks, > > Jun > > On Tue, May 5, 2026 at 10:29 AM Chia-Ping Tsai <[email protected]> > wrote: > > > Hi Jun, > > > > I totally agree that the name kafka-broker-api-versions.sh becomes weird > > once it supports showing controller-related information. While > > kafka-node-api-versions.sh is a good alternative, I'd like to propose > > taking it a step further: > > > > 1) Enhance the ClusterTool (kafka-cluster.sh) to support an api-versions > > command. > > 2) Deprecate kafka-broker-api-versions.sh. > > > > The reasoning is that the implementation becomes trivial if we leverage > > the existing Admin client logic in ClusterTool. This also helps us > > consolidate our command-line scripts and avoid further tooling > > fragmentation. > > > > What do you think? > > > > Best, > > Chia-Ping > > > > On 2026/05/05 16:51:03 Jun Rao via dev wrote: > > > Hi, Taiju, > > > > > > Thanks for the KIP and sorry for the late comment. > > > > > > The tool's name kafka-broker-api-versions.sh indicates that it's > intended > > > for the broker. So, it's a bit weird to use that to get the controller > > > info. It's probably clearer to have a new tool like > > > kafka-controller-api-versions.sh or rename the tool to something more > > > generic like kafka-node-api-versions.sh. > > > > > > Jun > > > > > > On Fri, Jan 9, 2026 at 3:42 PM TaiJu Wu <[email protected]> wrote: > > > > > > > Hi chia, > > > > > > > > Thanks for your suggestion, this idea looks can help us reduce > > maintenence > > > > overhead. > > > > I have updated KIP and draft PR. > > > > > > > > Best, > > > > TaiJuWu > > > > > > > > Chia-Ping Tsai <[email protected]> 於 2026年1月6日週二 下午11:42寫道： > > > > > > > > > hi TaiJu > > > > > > > > > > The current tool implementation manually constructs requests and > > parses > > > > > responses. I think that might be the right time to refactor it to > > use the > > > > > Admin client. > > > > > > > > > > What do you think about including the following changes in this > KIP? > > > > > > > > > > 1. Reuse the Admin client to handle request sending and response > > parsing, > > > > > replacing the manual implementation > > > > > > > > > > 2. Leverage KIP-1160 to send `ApiVersionsRequest` to specific nodes > > > > > > > > > > 3. Add an internal `InternalDescribeFeaturesResult` to expose > > > > `ApiVersion` > > > > > information. This would be used exclusively by the tool > > > > > > > > > > The main benefit is that the tool would be significantly > streamlined, > > > > > making it much easier to introduce support for the bootstrap > > controller > > > > > > > > > > Best, > > > > > Chia-Ping > > > > > > > > > > On 2025/10/29 00:55:50 TaiJu Wu wrote: > > > > > > Hi all, > > > > > > > > > > > > I would like to start discuss KIP-1220: kafka-broker-api-versions > > tool > > > > > > support bootstrap controllers. > > > > > > > > > > > > KIP: > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1220*3A*kafka-broker-api-versions*tool*support*bootstrap*controllers__;JSsrKysr!!Ayb5sqE7!q41M_Vt34jcinP10M2L21XbZwJthzAO63EUroy9f4HCEM4p5FFguZm14U3vvcps8KBoC1TeTsmHriGhWDQ$ > > > > > > JIRA: > > > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/KAFKA-19663__;!!Ayb5sqE7!q41M_Vt34jcinP10M2L21XbZwJthzAO63EUroy9f4HCEM4p5FFguZm14U3vvcps8KBoC1TeTsmGTh8N6Lw$ > > > > > > Draft PR: > > > https://urldefense.com/v3/__https://github.com/apache/kafka/pull/20598__;!!Ayb5sqE7!q41M_Vt34jcinP10M2L21XbZwJthzAO63EUroy9f4HCEM4p5FFguZm14U3vvcps8KBoC1TeTsmHXoQDUTQ$ > > > > > > > > > > > > Any feedback are appreciated. > > > > > > > > > > > > Best regards, > > > > > > TaiJuWu > > > > > > > > > > > > > > > > > > > > >
