Hi Sönke, There are a couple. The umbrella jira for these tasks is KAFKA-3268 <https://issues.apache.org/jira/browse/KAFKA-3268> . I personally raised KIP-248 <https://cwiki.apache.org/confluence/display/KAFKA/KIP-248+-+Create+New+ConfigCommand+That+Uses+The+New+AdminClient> to refactor the kafka-configs.sh scripts. I'd be happy to get some feedback on that (see the discussion thread for it) but if you're interested in refactoring a command, then I'd be happy to coordinate with you on that.
Viktor On Thu, Feb 22, 2018 at 4:29 PM, Sönke Liebau < soenke.lie...@opencore.com.invalid> wrote: > I've dug around jira and the list of KIPs for a bit now, but could not > really find anything specific on plans to move the command line tools over > to the new AdminClient. Did I miss something or is that not currently > planned? > > Most of the current command line tools require access to Zookeeper, which > becomes a bit of an issue once you enable zookeeper acls, as you need to > kinit with a broker keytab to be allowed write access which is somewhat of > a security concern. Also, if you want to firewall Zookeeper of from the > rest of the world any management command would need to be run from a > cluster machine. > None of this is an actual issue, it just required some additional effort > for cluster administration, however in a larger corporate environment I > can't imagine this would go down well with security audit guys and related > persons. > > Using the AdminClient on the other hand allows to give specific users the > right to create topics/acls etc.which is checked by the brokers and > requires no access to Zookeeper by anybody except the brokers. > > Maybe we could add a --use-adminclient parameter to the command line tools > sort of similar to the --new-consumer parameter to keep the old > functionality while enabling us to slowly move things over to the > AdminClient implementation? > > Best regards, > Sönke >