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
>

Reply via email to